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E-COMMERCE BID AND PROJECT MANAGEMENT SYSTEM 
AND METHOD FOR THE CONSTRUCTION INDUSTRY 



INVENTOR: LARRY ALLEN WARES 



FIELD OF THE INVENTION 

The present invention relates to construction industry bidding and project 
management system and methods. More particularly, the present invention relates to 
electronic commerce (e-commerce) based construction industry bidding and project 
management system and methods. Even more particularly, the present invention relates 
to electronic commerce (e-commerce) based construction industry bidding and project 
management system and methods, including document distribution, supply chain 
automation and on-line auctioning. 

BACKGROUND OF THE INVENTION 

In pre-construction phases, the construction industry traditionally relies on 
manual methods of bid collaboration, and dissemination of information and results. The 
bid manager's task is enormous and highly susceptible to inefficiencies and inaccuracies 
due to the predominantly manual means employed for completing the bidding task. 
Further, the construction industry professionals traditionally get bogged down with the 
multitude of tasks that not only have to be managed during the pre-construction bidding 
cycle, but also the multitude of tasks that have to be managed during the construction 
phase after the contract has been let. While the construction industry bidding process 
is well known, and is directed at obtaining the lowest possible price for the materials and 
labor, the bidding management tasks have not been centralized for being 
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comprehensively manipulated by available computer technology. Additionally, the 
subsequent tasks that need to be managed to track and monitor the construction project 
to completion are also limited to manual means. 

By example, in the pre-construction phase discussed above, the construction 
industry bidding task traditionally concerns: (1) an owner purchasing land and 
employing the services of an architect and other consultants, (2) an architect employs 
services of specialty engineers and consultants, (3) an architect prepares bid documents 
concerning the construction project involved, (4) architects and owners seek low bids 
from qualified general contractors, (5) general contractors seek low bids from qualified 
subcontractors and suppliers, (6) subcontractor seek low bids from suppliers, wholesalers 
and building products manufacturer, (7) suppliers and wholesalers seek low bids from 
specified building product manufactures, (8) building product manufacturers submit 
bids, (9) suppliers and wholesalers submit bids and (10) subcontractor submits bid, and 
(1 1) general contractors submit all-inclusive bid. The activities involved by each bidder, 
by example providing specifications, plans and drawings, for winning the lowest bid are 
intense and involves an enormous amount of manual manipulation and dissemination of 
information by each bid participant. 

Thus, while, there may be isolated computerized database for specifications, 
plans and drawings at the individual construction project participant's location, to 
applicant's knowledge, there are no known integrated computerized bidding and project 
management systems, other than the aforementioned non-integrated manual systems for 
manipulation and dissemination of information. 

Accordingly, a need is seen to exist for an e-commerce based bidding and 
construction project management system and method, whereby, a variety of integrated 
bidding and construction project related databases are provided to the construction 
community for being manipulating using on-line computerized telecommunications 
technologies, known as the internet, for being disseminated to the various participants 
in a construction project. 

It is therefore a primary object of the present invention to provide an integrated 
e-commerce based bidding and construction project management system and method, 
whereby, a variety of bidding and construction project related databases are provided to 
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the construction community for being manipulating using on-line computerized 
telecommunications technologies, known as the internet. 

Another object of the present invention is to provide an integrated electronic 
commerce (e-commerce) based construction industry bidding and project management 
5 system and methods, including document distribution, supply chain automation and on- 

line auctioning. 

BRIEF SUMMARY OF THE INVENTION 
Accordingly, the foregoing objects are accomplished by an integrated electronic 
commerce (e-commerce) based construction industry bidding and project management 

10 system and methods, including document distribution, supply chain automation and on- 

line auctioning. In a pre-construction setting, the e-commerce based bidding and 
project management system and method of the present invention provides for a user, such 
as an owner, and architect, engineer, consultant, general contractor, sub-contractor, 
retail and wholesale supplier and building products manufacturer, the means for 

15 participating and competing in the bidding and construction project management tasks 

using on-line computerized telecommunications technologies, known as the internet. The 
on-line system and methodologies, help the participant to achieve cost efficiencies and 
performance enhancements that traditional prior art manual bidding and construction 
management systems and methods have not achieved. 

1*0 The present invention is presently being marketed by buzzsaw.com, inc of San 

Francisco, California, and is accessible for on-line use at the website address of 
http:/buzzsaw.com/, (see generally the enclosed computer screen printouts labeled 
Attachments A, B, C and D ), enclosed herewith and incorporated by reference as if fully 
set forth herein. These computer screen printouts depict the graphical user interface for 

25 navigating through various on-line services available to the participant. Additional 

supporting material in the form of project specifications Attachment E, F and G used 
for the development of the present invention are also attached and are also incorporated 
by reference as if fully set forth herein. These attachments are described below: 
Attachment A. Home Page- Web Site 

30 Attachment B. Presently available On-Line Service 
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Attachment C. Specific Services Entitled: Screenshots 

Attachment D. Description Applicants S & E Company 

Attachment E. Functional Specifications For: Bid Manager-Phase 1 

Attachment F. Project Development & Manual 

Attachment G. Buzzsaw Bid System 
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CLAIMS 



What is Claimed is: 

1 . An e-commerce based construction industry bidding and project management system, 
said system comprising: 

5 facsimile and e-mail bid solicitation means for use by general contractors and 

subcontractors; 

a comprehensive database of subcontractors, suppliers and building product 
manufactures; 

bid collaboration tool means for architects, engineers, general contractors and 
10 subcontractors; 

means for selective downloading of electronic plan images; 

means for key-wording search and downloading of project specifications; 

means for networking blueprinters for hard copy reproduction of bid documents; 

means for submitting and processing electronic bid submissions; 
15 means for historical tracking of electronic bid results; and 

database means for providing e-mail services, weather reports, trade association 

links, and news & event information. 



2. An e-commerce based method of providing construction industry bidding and project 
20 management services, said said method comprising the steps of: 

providing facsimile and e-mail bid solicitation means for use by general 
contractors and subcontractors; 

providing a comprehensive database of subcontractors, suppliers and building 

product manufactures; 

25 providing a bid collaboration tool means for architects, engineers, general 

contractors and subcontractors; 

providing means for selective downloading of electronic plan images; 
providing means for key-wording search and downloading of project 
specifications; 

providing means for networking blueprinters for hard copy reproduction of bid 
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documents; 

providing means for submitting and processing electronic bid submissions; 
providing means for historical tracking of electronic bid results; and 
providing database means for e-mail services, weather reports, trade association 
5 links, and news & event information. 
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ATTACHMENT A 
HOME PAGE-WEB SITE 



buzzsaw.com 



Page 1 of 1 




Purchase products and service 
upgrades with our new online ordering 
system, new! 

buzzsaw.com hosts more than 2.000 
projects online! Read the latest press 
on our company. 

Learn more about who we are and what 
we do. 

Search for building products from 
more than 10,000 manufacturers. 

Monitor your project with a Web 
camera and maximize your site visits. 

Join our Customer Advisory Council . 

Collaborate with others in construction 
to help revolutionize the industry. 

Read the latest from Paul Doherty on 
the impact of Palm® and wireless 
connectivity on the built environment. 

Get trained on ProjectPoint every 
Thursday at 1 :00pm PST. 

Hear from Carl Bass , our CEO. 



W Job Opportgnltiti 
i*Priv*cy Policy 
fit Security Statement 




We offer everything from 

i project management services. 
I to Midifif product specs to 

" ori$inat industry news and more'! 
tod, we're <rmlm§ powerful bidding 
and e-cammerce solutions. 

biiizsaw.com 

wh*rt building projtctt happ*n! 



"When you're talking about saving time on 
projects, the big questions is 'What needs 
to get done today?' That's very important, 
and buzzsaw.com is getting us there." 

- Rich Mariand. DPR Construction, Ira 



http://www.buzzsaw.com/ 
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ATTACHMENT B 



PRESENTLY AVAILABLE ON-LINE 
SERVICE 



buzzsaw.com - Project Services 
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Project Services 



mam-mam 



Work on buzzsaw.com with these online 
services 



buzzsaw.com has a range of project services that help teams of architects 
engineers and contractors work faster and more efficiently. Start with these services 
to get the most out of working online. 



< > ■'/*: Proiect hosting : Sign up for ProjectPoint, the web-based project 
^ workspace for architects, engineers, and construction professionals 

<y ! It's easy, secure, and FREE! 



Online meetings : Host online meetings, redline documents 
concurrently and resolve issues in real time. Powered by WebEx. 



CAD tools : Get the latest, most relevant downloadable software! 



Web camera: Monitor job progress and resolve site issues from your 
office with a digital job camera. Real time updates! By Inet Architects 



Contact Us I Privacy Policy [ Terms & Conditions 



buzzsaw.com and the buzzsaw.com and ProjectPoint logos are registered trademarks of 
buzzsaw.com inc. in the USA and/or other countries. All other brand names, product names, or 
rademarks belong to their respective holders. ©Copyright buzzsaw.com, inc. All rights reserved 



http://ww.buzzsaw.com/content/services/index.html 
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ATTACHMENT C 

SPECIFIC SERVICES 
ENTITLED: SCREENSHOTS 



Press Room 



Page 1 of 1 



Screenshots 

Click a link below to download a screenshot of one of the many services offered on 
buzzsaw.com. 



buzzsaw.com home page 




View a larger version of this image. 
Download this image. 
(buzzhome.gif, zipped - 36 KB) 



bu zzsaw.co m online meetings 
— mm 




View a larger version of this image. 
Download this image. 
(webex.gif, zipped - 32 KB) 



buzzsaw.com web camera 




yView a larger version of this image. 
rOo wnload this image. 
=<webcam gif, zipped - 142 KB) 



projectpoint 




View a larger version of this image. 
Download this image, 
(projectpointgif, zipped - 60 KB) 



Contact Us | Privacy Policy | Terms & Conditions 

biizzsaw.com and the buzzsaw.com and ProjectPoint logos are registered trademarks of 
buzzsaw.com, inc. in the USA and/or other countries. All other brand names, product names or 
trademarks belong to their respective holders. ©Copyright buzzsaw.com, inc. All rights reserved 



http://ww.buzzsaw.com/content/about/screenshots.html 



1/27/00 



P1056PROV 



ATTACHMENT D 

DESCRIPTION APPLICANTS 
All About buzzsaw.com 



All About buzzsaw.com 



Page 1 ot'2 



All about buzzsaw.com 



buzzsaw.com is the building design and construction industry hub that delivers 
integrated business-to-business collaboration and e-commerce services for 
everyone in the building industry who needs a faster, more profitable way to work 
buzzsaw.com leads the market with the most accessible and complete place to 
work on the web. 



buzzsaw.com provides the building industry with integrated offerings for design 
collaboration, bidding, construction administration and buying. In addition, 
buzzsaw.com fosters an online community for information exchange by providing 
industry contacts, relevant reference material, pertinent news, and other services 
tailored to the needs of building professionals around the world. 

With its free project hosting and online industry resources, buzzsaw.com is 
transforming the building industry, buzzsaw.com makes it easy for everyone 
working on a building project to participate online by providing an array of services 
and intuitive tools. 



Founded in 1999 and headquartered in San Francisco, buzzsaw.com has 
established itself as the leader in Web applications and services for the building 
industry, buzzsaw.com is a privately held company backed by Autodesk®, Inc., the 
werld's leading supplier of PC design software and digital content creation tools for 
thfgbuilding industry. One of the largest software companies in the world, Autodesk 
has more than four million customers in over 150 countries. 

The Market 

Tie building design and construction industry is a $600 billion-plus industry in the 
US&alone and more than $3 trillion worldwide. In the US there are tens of 
thousands of building product manufacturers, hundreds of thousands of suppliers, 
aad millions of architects, engineers, and construction professionals all working on 
hfrjdreds of thousands of building projects. 

T§i| project is the basic unit of organization in the building industry. Firms, 
diiasions, individuals all organize themselves around individual projects to do 
specific tasks. All the work that gets done in design and construction-from the 
biggest office complex to the smallest renovation-is organized and measured the 
saTjie way: by project. 

Contractors, architects, engineers, managers, developers, reprographers, 
consultants-everyone involved in a building project-measure their success in 
terms of project success. A 'good' project is one that turns a decent profit. A bad 
project is unprofitable, which usually means it is late or behind schedule. A 
company's total profit is equal to the sum of its individual project profits, minus 
overhead expenses. 



Every project is unique, with its own site, its own program, its own requirements, its 
own mix of construction methodologies, and its own project team. Every building is 
a prototype. Building projects face a high degree of risk, and it's the job of project 
managers to control expenses and budgets tightly in order to make money. 

Project managers on all sides-design, construction, and development-work 
together as well as they can to keep information moving and decisions happening 
in order to make deadlines and meet milestones. A project manager's ability to do 
this job well depends entirely on their individual skills as a manager and their 
access to tools that allow them to monitor and manage their projects. 

The tools for successful building project management 



http://www.buzzsaw.com/content/about/backgrounder.html 
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buzzsaw.com allows all building design and construction professionals to optimize 
profitability by providing them with tools that improve efficiency in the specific ways 
unique to each project. With the most complete and accessible set of Internet 
applications and services for the building industry, buzzsaw.com enables project 
managers and participants to choose the right tools for each project, thereby 
improving the flow of information to everyone. 



Every member of buzzsaw.com's senior management team has building industry 
domain expertise, software application development experience, and Internet 
technology know-how. ProjectPoint, buzzsaw.com's secure design collaboration 
hosting service, was designed by building design professionals for everyday use in 
todays building industry. To date, ProjectPoint has been utilized on many 
successful building projects, and continues to spread to new users everyday. 

The constant, overriding goal for building industry professionals is to wrap up 
whatever project they are on and move on to the next one. Invoices get paid only 
after work is completed. From an economic standpoint, firms in the building 
industry face up-front fixed costs (such as purchasing of materials, equipment and 
other startup costs) and ongoing variable costs (primarily labor and consumables) 
on every project. That means the sooner they finish a project, the less that project 
costs them and the higher their profit margin. One extra, unplanned day of work for 
one crew could mean the difference between profit and loss for a subcontractor 
Minimizing project overruns and delays is critical to everyone's profitability 
buzzsaw.com is a powerful resource that improves communication and eliminates 
ngmy of the variables that can negatively affect the bottom line 



Contact Us [ Privacy Policy I Terms & Conditions 

="= buzzsaw.com and the buzzsaw.com and ProjectPoint logos are registered trademarks of 
s = buzzsaw.com inc. in the USA and/or other countries. All other brand names, product names 
yi or trademarks belong to their respective holders. ©Copyright buzzsaw.com, inc. All rights 
reserved. 
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ATTACHMENT E 



FUNCTIONAL SPECIFICATIONS 
FOR 

BID MANAGER-PHASE 1 



Functional Specifications 
Bid Manager - Phase I 



Executive Summary 

Bid Manager is a Pre-Construction Services Portal that enables commercial construction communities to 
participate in more efficient and cost effective bidding practices. 

The construction industry traditionally relies on manual methods of bid collaboration, and while two of the 
industry's leading news and project information services have improved the offering of computerized data, 
no single entity has attempted to provide a comprehensive mechanism that offers all of the components 
required to process an accurate and timely bid. In addition to offering news and information about 
upcoming bids, Bid Manager's portal will enable a more efficient connection of audiences by providing the 
following services: 

1. Fax and E-mail Bid Solicitation for General Contractors and Subcontractors 

2. Comprehensive Database of Subcontractors, Suppliers and Building Product Manufactures 

3. Bid collaboration tools for Architects, Engineers, General Contractors and Subcontractors 

4. Selective downloading of electronic plan images 

5. Key-word search and downloading of project specifications 

6. Networking over 1 ,200 blueprinters for hard copy reproduction of bid documents 

7. Electronic Bid Submission 

8. Historical tracking and electronic Bid Results 

9. General services including e-mail, weather, trade association links, news & events, Etc. 
Bid Manager's success will be directly related to the following critical assumptions: 

1 . Plans and specifications can be seamlessly converted from their native .dwg format to a "Read 
Only" format that can be utilized for viewing, electronic estimating and digital printing 

2. Development of a security mechanism that offers all levels of open or restricted access 

3. An application interface that combines standard design and usability features with the 
idiosyncrasies of the construction community 

4. Utilization of the best available technology for the internet 

In an industry where time and information are highly strategic components of the "New Business" process, 
Bid Manager stands to offer what nearly all successful business are willing to pay for - A tool that 
minimizes resources and increases profits. We have the technology. Data and other critical business 
components are readily available. The construction industry has been primed for Bid Manager. Raw talent 
and speedy execution will determine the stake that claims this new and exciting space. 



Prepared By Larry Wares 
March 30, 1999 



Industry Overview 



The systematic, almost methodical, bid process experienced by today's construction industry is a result of 
nearly 150 years of competitive bidding; and while the projects and players may differ from bid to bid the 
goal remains unchanged - To obtain the lowest possible price for the best possible materials and labor. 

Byproducts created from the evolution of this process were eventually converted to standards. 
Construction professionals in North America and Canada have adopted many of these bid practice 
standards, one of which is the final deadline for bid submission at 2:00 PM -- ala Bid Manager. In addition 
to bid submission standards architects and engineers believed that organization of the bid documents by 
trade discipline would result in better bids. Today plans and specifications are prepared in a way that 
enables all participants to narrow down their required scope of work and submit a qualified bid. The model 
below represents how the organization of bid information resulted in a complementary business hierarchy: 



Owner 



Architect 
& 

Engineers 



General Contractors 



Subcontractors 





Suppliers 






& 






Wholesalers 








Building 


Product 


Manufactures 



1 . Owner purchases land and employs the 
of an architect and other consultants 

2. Architect employs services of specialty 
engineers and consultants 

3 . Architect prepares bid documents 

4. Architect and owner seeks low bids from 
qualified general contractors 

5. General contractors seek low bids from 
qualified subcontractors and suppliers 

6. Subcontractors seek low bids from suppliers, 
wholesalers and building product manufactures 

7. Suppliers and wholesalers seek low bids from 
specified building product manufactures 

8. Building product manufactures submit bids 

9. Suppliers and wholesalers submit bids 

10. Subcontractors submit bids 

11. General contractors submit all-inclusive bid 



While the above model appears to conform to a typical business transaction structure one should note that 
an intense strategy for winning the low bid exists within system. The community will not accept merely 
providing a better vehicle for information dissemination - they will expect to maintain their ability to 
prepare a competitive bid. The framers of Bid Manager must be cognizant of the specific requirements of 
competitive bidding as outlined in sections to follow. 
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Bid Process Overview 



This section will describe the fundamental steps of the bid process. Emphasis will be placed on describing 
the unique roll each segment plays in the process. Bid Manager's infrastructure and interface should be 
flexible enough to accommodate "Look and Feel" customization by segment. 

Types of Bids 

Bid Manager will be primarily designed to meet the needs of the commercial/industrial and building 
industry; however, consideration for US infrastructure projects such as roads, dams and bridges should be 
implemented into the roots of the system for future use (see supplemental infrastructure design documents). 

There are typically five (5) types of bid scenarios - they are as follows: 

1. Public Works (City/State/Federal Government) - Typically public works projects are open 
to anyone and everyone that qualifies to bid the project. Highly competitive bid environment. 
Strong consideration for "Equal Opportunity Employment" exists in most states. Preferential 
bidding, based on race, continues to be challenged across America. No such bidding criteria 
exist in Canada. Fields describing Minority, Women, Disadvantaged Veterans and Small 
Business may become a critical option for database design. 

2. Private Competitive Bid - Private ownership(s) where more than one General Contracting 
bid is desired. Heavy competition amongst general contractors and subcontractors. 
Provisions for Union Labor may be required if funds come from Union lending institutions. 
Prevailing labor rates may be mandated if a portion of the funds come from a Government 
funding program. Database design should allow for identification of Union or Prevailing 
Wages. 

3. Negotiated Bid - Ownership places confidence in a single General Contractor. General 
Contractor will solicit bids from qualified subcontractors and suppliers. Provisions for Union 
Labor may be required if funds come from Union lending institutions. Prevailing labor rates 
may be mandated if a portion of the funds come from a Government funding program. 
Database design should allow for identification of Union or Prevailing Wages. 

4. Design/Build - Ownership selects one general contractor to assist architect with design and 
bid documents in order to meet the constraints of the development budget. Some design/build 
contracts call for the General Contractor as the lead in lieu of the Architect. General 
Contractor will solicit bids from qualified subcontractors and suppliers. Provisions for Union 
Labor may be required if funds come from Union lending institutions. Prevailing labor rates 
may be mandated if a portion of the funds come from a Government funding program. 
Database design should allow for identification of Union or Prevailing Wages. 

5. Re-Bid - Sometimes a project will either come in over budget or the economy may adversely 
change and delay the bid award process. In these case a project may com out as a re-bid. For 
this reason provisions within the database design must accommodate re-bid projects. 



Project types 2, 3 and 4 will require tight security controls that empower the owners, architects and general 
contracts with the ability to keep the project from getting into the hands of their competitors. This will be 
of great concern to Owners, architects, engineers and general contractors. 
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The Owner 



Owners are typically comprised of the following entities: 

1. Single entity/private ownership 

2. Partnerships and joint ventures 

3. Corporations (Wal-Mart, McDonalds, Etc.) 

4. City, State and Federal Government agencies 

While the owners roll in the bid process is typically limited to performance motivation, they will always 
want to have their fingers in every aspect of the process. The owners' main goal is to secure the financing 
and employ consultants that meet or beat the expectations of the financial pro forma. 

Identifying qualified consultants and collaborating within Bid Manager will provide great value to the 
owner. Typical collaboration expectations from the owner are as follows: 

1 . Delivery of Request for Proposals (REP' s) to qualified architects and engineers 

2. Exchanging design and building program requirements with architects and engineers 

3 . Identifying qualified consultants and requesting information about their services 

4. Organizing meetings and job site visits with team members 

5. Identifying qualified general contractors by work type and prior performance 

6. Delivery of Request for Proposals (RFP's) to qualified general contractors 

7. Reproduction and delivery of plans and specifications 

8. Searching for and viewing currently available building product materials and requesting 
preliminary pricing 

9. Providing press releases and other public relations information 

10. Marketing and sales of real estate 

The owner of the project will become a key advocate of Bid Manager's efficiency capabilities. 



Architects and Engineers 

Architects are typically expected to lead the bid process. Following receipt of a signed contract from the 
Owner the Architect will commence preparation of the following documents: 

1 • Preliminary schematics - Typically consists of a site plan, floor plan and conceptual 
elevations. 

2- Preliminary plan submission to City - Agency specific requirements, but typically includes 
preliminary schematic documents accompanied by form documents provided by the local City 
or County. 

3- Preparation of Bid Documents - Consists of all documents required to accurately bid the 
project. Bid documents also include Addenda - a change to the original bid documents. 

4. Plan Check - Submission of final design documents for code and occupancy use review and 
approvals. Generally consists of all bid documents and any changes resulting from the bid 
process. 

5- Construction Documents - Modified bid documents incorporating all comments from bidding 
process and plan check. Documents used to construct project. 

6- Contract Administration - Some Architects may also coordinate prime contract agreements 
and perform other contract administration activities for the owner. 

Critical elements for Bid Manager and the Architect are as follows: 
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1. Project information - Each project will be set up with its own unique profile. The architect 
must be able to quickly point and click on Bid Manager's pre-defined lists. Preferences must 
allow non-applicable list items to be hidden for quicker set-up. Project information may 
include, but may not be limited to the following: 

a. Title 

b. Location 

c. Bid Date and Time 

d. Owner Information 

e. Architect Information 

f. Consultant Information 

g. G.C.'s Bidding Information 

h. Type of project (Up to 25 types) 

i. Estimated valuation 

j . General Scope of work description ( 1 00 words) 

k. UCI/CSI list of trades or key word indexing on disciplines required 

Note: A cumulative list of bid participants by segment should be tracked and made 
available at the request of the security administrators. 

2. Bid document formats and organization - Every project consists of plans, specifications, 
addenda and other related documentation. The purpose of these documents is to provide a 
consistent format for bid submission and create the basis for executing future contracts. 

a. Plans - Plans are typically prepared in a computerized format called ".dwg". Bid 
Manager's architectural interface must provide for simple project set-up and 
administration by the architect. Architects will not allow their .dwg files to be 
publicly disseminated. Painless file conversion will be required for the following 
critical purposes: 

1. Painless viewing while on-line 

2. Downloading for electronic estimating 

3. Downloading for digital printing 

Individual plan sheets must be organized in folders by consultant discipline as 
follows: 

1. Architectural 

2. Structural 

3. Plumbing 

4. Mechanical/HVAC 

5. Electrical 

6. Landscape 

7. Civil 

8. Other 

Note: If plans are not available in electronic format all efforts should be made to 
link the designated printer to the bid team for easy ordering of bid documents. 

b. Specifications - Specification books are typically prepared in an electronic word 
processing program. All specification booklets will be converted to .pdf file format 
and organized by the industry standard UCI/CSI major division codes as follows: 

01 - General Requirements 

02 - Site Work* 
03 -Concrete 

04 - Masonry 

05 - Metals 
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06 - Woods and Plastics 

07 - Thermal and Moisture Protection 

08 - Doors and Windows 

09 - Finishes 
10 -Specialties 
1 1 - Equipment 
12 -Furnishings 

13 - Special Construction 

14 - Conveying Systems 

15 - Mechanical 
16 -Electrical 
17 - Other 

* Note: Soils report documents will be contained within division 02 - Site Work 



c. Addenda - Addenda must be treated as "Urgent" documents throughout the 
architecture. Addenda change bid dates, bid documents and bid meetings on a 
regular basis. Accurate bid submission is contingent on timely receipt of addenda 
information. A separate and distinct folder will house all addenda information and 
will be organized as follows: 

- Addenda 

- Addenda 1 March 23, 1999 

Plans 
Specs 

- Addenda 2 April 2, 1999 

Plans 
Specs 

Indexing all addenda information into a search index would greatly enhance the 
industry addenda processing problems. (Key word match and group by major CSI 
division) E-mail and paging services should be linked to the addenda processing 
system. 



Other Correspondence - Architects and Engineers will require other basic tools for standard 
bid collaboration. The action list below represents a preliminary list that may change as 
feedback is received from beta testers: 

a. RFI Processing - RFI's or Request for Information correspondence is critical during 
the bid phase. General contractors often receive questions from qualified 
subcontractors regarding product specifications, installation details and/or alternate 
material submission. RFI's typically create addenda. Addenda legally modify the 
bid documents. The RFI processor is a simple word processing tool that 
automatically tracks and forwards information to the correct team menders - similar 
to Project Net's Submittal Processing system. 

b- Alternate Product Inquiry - Building Product Manufactures often submit requests for 
alternate materials when their product names are not listed in the specification book. 
Architects need an organized submission vehicle and a simple form of approval 
processing. HTML linking within the inquiry to the BPM's web site may greatly 
enhance this process. 

c- Pre-Bid Meeting Notification - Some projects require a pre-bid conference with the 
architect and the owner. Home Depot never bids a job without a pre-bid conference. 

d. Electronic Bid Submission - Most bids are submitted in person today; however, Bid 
Manager may modify this protocol. For this reason the system must support 
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electronically submitted bids. The architect will want to create a bid form so that all 
the bids are consistent and easily evaluated. Contractors will simply fill in the blanks 
and click on SUBMIT BID NOW. The "submit bid now" screen would look nice 
with an analog clock in the corner! 

e. Bid Withdrawal Form - Contractors often withdrawal from the bid process. A form 
with predefined reasons for the withdrawal will be helpful to notify all involved in 
the bid process to-date. 

f. E-mail - We may want to provide free e-mail services. 



The Print Network 

A key ingredient for Bid Manager's success is the ability to process comprehensive reproduction services 
for plans and specifications. In a perfect world the architect will submit plans and specifications in formats 
that can be painlessly converted to printable images as outlined above. A significant portion of Bid 
Manager's e-commerce plan is to link digitally enabled printers to the audiences requiring hard copy plans 
and specifications. The print processing network should be designed as follows: 

1. Utilizing the document organization structure shown above, the ordering system must allow 
picking and choosing of individual plan sheets and specification sections. Use "Add to 
shopping cart" methodology. Each set of bid documents must be packaged and re-capped by 
job title. 

2. Provide for "frequent flyer" purchasing and/or large order discounts. 

3. Provide comprehensive ordering, fulfillment and billing system. (Fed-x partnering?) 

4. Potential for automatic profiled delivery system. (Painting sub wants Architectural sheets and 
section 09900 of the specifications delivered each week within a designated geographic 
location) 



The General Contractor (GC) 



The GC is responsible for providing an all-inclusive turnkey bid for the project. GC's are bound to their 
bid by language contained within the bid documents. The challenge for the GC is to get as many 
competitive bids as possible from qualified subcontractors and suppliers before the 2:00 PM deadline. Bid 
Manager will greatly enhance the GC's competitive capabilities by providing the following basic services: 

1 . Search for, or automatically receive, new bidding opportunities 

2. Organizing and tracking a list of pre-qualified subs and suppliers 

3. Access to hundreds of thousands of subs and suppliers that are organized by UCI/CSI trade 
codes 

4. Automated fax and e-mail bid solicitation to subs and suppliers 

5. Automated bid response from subs and suppliers 

6. Automated print processing of plans and specifications from print network 

7. Quick and simple RFI submission to architects and engineers 

8. Speedy notification and delivery of addenda information 

9. Easy processing of "Scope Letters", "Bid Memos" and "Bid Submission Forms" to team 
bidders 

10. "Work from Anywhere" bid collaboration platform 

1 1 . Electronic bid submission from subcontractors and suppliers 

12. Electron bid submission to Architects 

13. Historical tracking and 24 nr. monitoring of bid process 

14. Multi station bid processing within one seamless platform 

15. Automated purchasing and award notification (contract processing) 

16. Easy transition to "Web-based Project Management" 
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Following is a brief description of how each of the above features will function within the Bid Manager 
environment: 

1- Search for, or automatically receive, new bidding opportunities (marketing) 

a GC's will utilize the "Project Data" as entered by the architect to find new bidding 

opportunities. Locating all industrial tilt-up bidding opportunities in a geographic region 

is one example of this valuable search benefit, 
b Many GC's will pay for Bid Manager to automatically deliver bidding opportunities 

based on pre-defined criteria. GC's can retrieve the data at any time while the system 

updates the mailbox, as new data becomes available, 
c After the project list is drilled down the GC will want to deliver a "Request to Bid" 

inquiry to either the architect or owner. This may become a form letter within Bid 

Manager. 

d A simple project tracking and calendar system will help GC's track and manage their 
bidding opportunities. 
2. Organizing and tracking a list of pre-qualified subs and suppliers 

a. GC's will want to maintain and track their own private list of subs and suppliers. Bid 
Manager's database structure should allow GC's to manipulate and manage two sets of 
intelligent data. Subs and suppliers should also be capable of updating the profile 
directly, only if the GC's admin preferences are set accordingly. 

b. The database structure will mimic a typical contact management database, but will be 
uniquely organized by the UC1/CSI code indexing system. A one-to-many relationship 
must be available for subs and suppliers that perform more than one trade. 

c. Standard report writing should be provided for creation of printed lists. 

d. Basic import and export capabilities must be supported for easy set-up of the bidder list. 
3- Access to hundreds of thousands of subs and suppliers that are organized by UCI/CSI trade 

codes 

a. This will be a major benefit of Bid Manager's product offering. GC's will use this data 
as a supplement to their private database of subs and suppliers. Similar to section 2 
above, all data will be organized by the UCI/CSI index of codes and will be managed in a 
typical contact management database environment unique to construction bidding. 

b. GC's must have the capability of moving data from the public list to their own private 
list. A distinction between the origin of data must be provided prior to adding to private 
list. 

c. Subs and suppliers that pay for advertising will be listed in "Top-of-List" priority for easy 
selection by the GC. 

d. General use fax and e-mail templates should allow quick and easy communications 
directly from the private or public list of subs and suppliers. 

4. Automated fax and e-mail bid solicitation to subs and suppliers 

a. The Bid Management capabilities of Bid Manager will become the heart of the product. 
GC's will need to organize a bid list quickly and notify qualified subs and suppliers by 
fax and e-mail. 

b. Each project must be organized as its own entity. Many projects will be set-up by the 
owner or architect and forwarded to the GC for bid processing. Not all projects will be 
set up by the architect. GC's will use Bid Manager without electronic plans and specs. 

c. All bids will be organized by UCI/CSI code indexing. Filtering out subs and suppliers 
by fields representing geographic bidding preferences will be supported. Locating subs 
with labor and other work preferences will also be required. 

d. A point and click selection process will allow the GC to narrow don a preferred list of 
subs and suppliers. 

e. Templates will enable quick and simple broadcast fax and e-mail processing. 

f . Printed reports will facilitate the requirements of hard copy documentation. 

g. Non bid related faxes and e-mails must be permitted within the system. 
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h. A 1-800-fax response server will be used to automatically rout RSVP's back to the 
appropriate GC. OCR recognition capabilities will be required for fax routing. 

i. GC's will require bid solicitation activity reports showing bid coverage by UCI/CSI 
trade. If bid response is low additional faxes and e-mails will be sent to subs and 
suppliers selected from the public list. 

j. Proof of "Good Faith" solicitation to qualified minorities, women, disadvantaged 
veterans and small business may be required on certain public works bids. 

5. Automated print processing of plans and specifications from print network 

a. Over $2.0 billion is spent each year on reproducing bid documents. Fed-x collects over 
$300 Million from shipping plans in tubes. Bid Manager will greatly enhance the 
printing and decimation process. GC's must have the capability of pre-purchasing plans 
for a select group of subs and suppliers. All other interested subs and suppliers must 
directly purchase from the printer. Pre-purchased plan information is not for public use. 

b. GC's will want to submit an order to several vendors to obtain the best possible printing 
price. 

c. The bid document-ordering module should be a unique feature of the interface - easy-to- 
use and reliable. 

6. Quick and simple RFI submission to architects and engineers 

a. GC's will need a simple template to create, submit and tract questions submitted to 
architects and engineers. 

b. Utilize pull-down lists make RFI's easy to prepare and send. 

c. Some of the RFI's will be directly forwarded to the architect as they come in from the 
subs and suppliers. Admin preferences should allow automatic forwarding with copies in 
the GC's inbox. 

d. History tracking will be required. 

7. Speedy notification and delivery of addenda information 

a. The average bid experiences 5 addenda prior to bid day. Some projects will have 50 to 
100 addenda. Addenda consist of revised bid dates, modified plans and specs, and 
adjusted meeting dates and times. 

b. All addenda information will be housed in a separate folder called "Addenda" with sub 
folders called "Plans" and "Specs". 

c. Special fields will be provided to capture modified bid dates or meeting dates. Other 
buttons may be used to signify changed plans or spec sections. 

d. A key-word index can be used for automatic notification or search inquiry of trades 
affected by the addenda. 

e. Addenda are typically labeled 1-N or A-Z. 

f. All electronic bid submission templates should note receipt of addenda, i.e. This bid 
includes the following addenda. . . 1, 2, 3 and 4. 

8. Easy processing of "Scope Letters", "Bid Memos" and "Bid Submission Forms" to team 
bidders 

a. GC's will use templates to organize questions and broadcast them to certain members of 
the bid team. This feature will help maintain, and possibly increase the GC's competitive 
edge. 

b. All templates are UCI/CSI code driven - pull down list of codes. 

c. Uses pull-down list of bid team based on selected codes for memo or scope letter. 

d. Will need to fax and e-mail forms, similar to bid solicitation. 

e. Unique folders house responses from subs and suppliers. 

9. "Work from Anywhere" bid collaboration platform 

a. Bid set-up stuff ! Not complete yet! ************************** 

10. Electronic bid submission from subcontractors and suppliers 

a. GC's will receive bids from subs and suppliers. Allowing the GC to prepare a custom 
bid form for each bid will help facilitate a consistent retrieval and bid evaluation process. 

b. Many subs and suppliers will use a standard e-mail attachment protocol for submitting 
bid proposals. (Attach an Excel or Word file) 

c. Subs and suppliers will want verification that the bid was delivered successfully. 

11. Electron bid submission to Architects 
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a. Architects may want to prepare bid forms that can be submitted by the GC. GC's can fill 
in the blanks, add information and submit the bid via Bid Manager. 

12. Historical tracking and 24 hr. monitoring of bid process 

13. Multi station bid processing within one seamless platform 

a. Large projects often require the efforts of several employees. Bid Manager should allow 
real-time access by to all levels of the application. 

b. Standard AIA contract documents control 90% of the industry's agreements. Automating 
this piece of the business will require creativity and vision. 

14. Automated purchasing and award notification (contract processing) 

a. After a bid is awarded GC's will need to lock-in material prices. Bid Manager should 
provide a simple contract purchasing and award processing system. This system will 
ultimately drive most of Bid Manager's future revenue. 

15. Easy transition to a standard project management package (Primavera, Meridian Systems, etc) 
a. If a bid team utilizes Bid Manager to win a bid they will be highly motivated to continue 

the construction management process in a similar environment. 



Subcontractors 

It is important to understand that the subcontractor is the lifeblood of the general contractor. Deep 
relationships are nurtured and maintained in order to combat heavy bid competition. Bid Manager will 
flourish if the subs can enhance their bonds with the GC. The framers of Bid Manager must incorporate the 
ability to collaborate in an environment that is easy to use and highly secured. 

While some of the more sophisticated subs will perform similar functions as the GC, the vast majority will 
expect the following capabilities: 

1 . Search for, or automatically receive new bidding opportunities 

a. Searching by using one or more of the following criteria will be required (including 
Boolean logic): 

1. UCI/CSI trade 

2. Key word(s) 

3. Project type (commercial, schools, retail, etc.) 

4. Geographic Location 

5. Valuation 

6. # of Days before bid is due 

b. Set preferences and have data automatically delivered to bid inbox 

c. Manage bidding opportunities in a calendar package similar to or linked to Outlook 

d. Directory services activity automatically sent to sub 

e. Directory services link to sub's web site 

f . Creation of a custom portal for the sub 

1 . Marketing and promotion 

2. Manage relationships with BPM's 



Suppliers, Wholesalers and Building Product Manufactures 

One of the greatest challenges for the BPM segment is locating new projects during the design phase. As 
the Bid Manager piece becomes more populated with data the BPM will see great value in having access to 
the information. The BPM segment will require the following capabilities: 

1 . Same as sub above, and. . . 

2. Receiving e-mail and fax leads from subs and G.C.'s 
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3 . Sending quotes and/or bids to subs and G.C. ' s 

4. Locating projects containing their own products or the requirement for similar products 

5. Hot-linking anyone to the BPM web site 

6. Creation of a custom bid portal that meets Bid Manager standards for future e-commerce 
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1.0 Executive Overview 



1.1 Proposal Overview 

This proposal outlines the requirements and approach required to design and implement Phase 1 of the 
Convex Bid Manager. Additionally, the proposal presents a review of the Requirements Definition 
Workshop conducted by logical-E and Primix. The results of the Requirements Definition Workshop 
form the basis for this proposal. Additional activities undertaken by logical-E and Primix since the 
completion of the workshop are also reflected in the proposal. 

1.2 Review of Requirements Definition Week 

During the week of June 22-26,1999, representatives from logical-E and Primix met with Larry Wares, 
CEO of Convex, to define the requirements for the proposed web-based system that, when completed, 
has the potential to transform the construction industry. The objectives of the Requirements Definition 
Week were as follows. 

• Develop a comprehensive set of functional requirements for Phase 1 of the Convex web-based 
project 

• Identify a set of high-level functional requirements for Phase 2 & 3 of the Convex web-based project 

• Develop approximately 4-6 'mock-up' pages, based on functional requirements identified early in the 
week, to demonstrate the preliminary look and feel of the web site 

• Develop a catalog of the required Phase 1 web pages 

• Develop an initial enterprise web architecture strategy and database design 

• Develop an initial Phase 1 project plan and budget estimate 

An interactive format was utilized throughout the week that enabled meaningful dialogue to take place 
between the participants. The overall vision for the web-site was presented by Mr. Wares and a variety 
of topics including the web site's user interface, the system architecture and database, hardware 
requirements, system performance, and security issues were discussed. A considerable amount of time 
was spent clarifying the respective scope for each of the initial three phases. The description of the 
initial three phases that follow represent our summary understanding of what will be required in each 
phase as the project moves forward. 
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The outputs associated with each of the workshop's objectives can be found in respective sections of the 
proposal. All of the participants from logical-E and Primix would like to express their gratitude to Mr. 
Wares for the amount of time and energy he brought to the workshop and look forward to the 
opportunity of working with him in the future. 

1.3 Project Description 

Phase 1 

The initial phase of the Bid Manager project will focus on the creation of a web-based system that will 
transform the current pre-construction bid practices into a more efficient and cost effective process. The 
objective for Phase 1 is to go to market as quickly as possible with a robust, scaleable, and easy to use 
web site that meets the needs of key stakeholders. The Phase 1 functionality focuses heavily on 
messaging and document management but it is essential that Bid Manager be designed and built with 
subsequent phases in mind given the product's ultimate movement into the electronic commerce 
marketplace. The primary stakeholder groups targeted in Phase 1 are the General Contractors and 
Subcontractors although the site will be made available to other stakeholder groups, particularly 
Architects and Engi neers. The functionality in Phase 1 will be developed to not only capture 'eyeballs' 
but also to provide real value in reducing the level of effort required to develop, manage, and submit 
bids. The ability of Phase 1 to entice General Contractors and Subcontractors to keep returning to the 
site is critical to the overall success of Bid Manager as it moves forward into the additional functionality 
to be delivered in subsequent phases. The implementation date for Bid Manager Phase 1 is 4 th quarter of 
1999. 

Phase 2 

Bid Manager Phase 2 includes the networking of over 1,200 blueprinters for the hard copy reproduction 
of bid documents. The overall depth of the Phase 2 functionality is yet to be determined but, at a 
minimum, Bid Manager's messaging backbone will be utilized to notify participating blueprinters of 
requests for documents. Another consideration for Phase 2 will be the status of the proposed alliance 
between Convex and Autodesk. If this alliance moves forward, it is possible that a portion of Phase 2 
scope could include the electronic movement of plans and drawings through Bid Manager. This step is 
seen as critical to the overall vision for Bid Manager given the proposed functionality planned for Phase 

Phase 3 

Bid Manager Phase 3 will deal with the full integration of the construction industry supply chain in that 
several key linkages will be made which will transform the industry as it currendy stands. Phase 3 is still 
in the planning stages but there is the possibility that it will run concurrently with Phases 1 & 2. The kev 
elements of Phase 3 involve the linkage of electronic plans and specifications (.dwg format) to Bill of 
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Materials associated with the specific materials which match the requirements outlined in the plans and 
specifications. These Bill of Materials can then be used to build on line orders through the use of on-line 
material and supply catalogs. The ability to link electronic plans and specifications with specific Bill of 
Materials that can then be electronically ordered would transform the construction industry by 
dramatically increasing the efficiency and effectiveness of the overall process. 

1.4 Project Plan 

The Scope runs from a proposed start date of 7/19/99 to 7/23/99. The outcome of this week would be 
the functionality matrix and consensus regarding the features and functionality if Phase One that we can 
deliver by the desired date. The design phase will begin on 7/26/99 immediately following the scoping 
session. We are allocating 5 weeks for design however will attempt to complete this in 4 weeks. In order 
to meet the aggressive overall timeframe it is suggested that the revised development plan be delivered by 
8/20/99. 

The Project design team will work at the CONVEX Technologies site for the UI Design Phase. We 
anticipate that the entire design team will require six (6) consultants. 

1.4.1 Milestones 

Milestones are key points in a project where demonstrable progress can be seen. The suggested 
milestones for the Scope & Design Phase are given in the following table. 



Milestone 


Date Due 


Scope Start 


7/19/99 


Scope Completion with Functionality Matrix 


7/23/99 


Design Start 


7/26/99 


Delivery of functional sections for review 


7/13/99 


Delivery of Interface Simulation 


7/13/99 


Delivery of revised development plan 


8/20/99 


Delivery completed design for review 


8/27/99 



1.4.2 Deliverables 

There are three deliverables to CONVEX Technologies at the end of the Design Phase. These are the 
Design Document, the mock up (Interface Simulation), and a revised development plan. 

The Design Document will be delivered in two installments. The first installment will consist of the 
functional sections. A mock up of the screens will also be delivered. Together the first sections and the 
mock up comprise the functional baseline for the Phase One system. A complete Design Document will 
be delivered after the technical design. In addition a revised development plan will be provided to 
CONVEX. 
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This Phase will be comprised of the functionality matrix design/approval process and Bid Manager's 
functional design and the technical design. The purpose of this phase is to finalize the detail of the 
required screen layout and supporting functionality. Primix and logical-E determined that the effort 
required to complete this process will require five (5) weeks, seven (7) consulting skill-sets to cover the 
required range of technical disciplines, a Client Partner and additional intermittent personnel support as 
required to deliver specific core expertise. Deliverables provided at the end of this phase will include the 
Design Document, consisting of the functional and technical specifications, the screen mock-ups, and a 
detailed development plan. As mentioned above, a delivery from Design will be a Fixed-Time/Fixed- 
Cost bid for Bid Manager's Development Phases. Per CONVEX's direction, Primix and logical-E 
anticipate beginning the Design Phase on Monday, July 19 th . Primix and logical-E will deliver the 
complete Design Phase for a fixed price of $291,000. 

1.5 Development Phase Project Plan 

1.5.1 Schedule 

In essence, the development runs from a proposed start date of 9/ 6/99 to delivery of the system-tested 
application on 11/26/99. 

1.5.2 Milestones 

The suggested milestones for the Development Phase are: 



Milestone 


Date Due 


Development Start 


9/7/99 


Software and Hardware Setup 


9/13/99 


Completion of Implementation 


11/5/99 


Completion of Integration testing 


11/12/98 


Completion of System Testing 


11/26/99 



The hardware requirements will be finalized two weeks from the official start date. It is expected that the 
hardware be available for the start of development. 

1.6 Best-Estimate Price for Development 

The Development Phase is comprised of the implementation and integration stages. The purpose of this 
phase is to take the detailed technical and functional designs that evolved from the Design Phase to build 
unit tested coded components. These units will then be integrated and tested before being deployed. 
Our current best-estimate range for Bid Manager's Development Phase is 3800,000 to $1,200,000. Once 
again, a Fixed -Time/ Fixed-Cost proposal for the Development Phase will be delivered upon completion 
of the Design Phase. 
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2.0 Functional Requirements 

2.1 CONVEX Bid Manager Project Summary Overview-Phase 1 

The initial phase of the Bid Manager project will focus on the creation of a web-based system that will 
transform the current pre-construction bid practices into a more efficient and cost effective process. The 
objective for Phase 1 is to go to market as quickly as possible with a robust, scaleable, and easy to use 
web site that meets the needs of key stakeholders. The primary stakeholder groups targeted in Phase 1 
are the General Contractors and Subcontractors although the site will be made available to other 
stakeholder groups, particularly Architects and Engineers. The functionality in Phase 1 will be developed 
to not only capture 'eyeballs' but also to provide real value in reducing the level of effort required to 
develop, manage, and submit bids. The ability of Phase 1 to entice General Contractors and 
Subcontractors to keep returning to the site is critical to the overall success of Bid Manager as it moves 
forward into the additional functionality to be delivered in subsequent phases. The implementation date 
for Bid Manager Phase 1 is early 4 th quarter of 1999. 

2.2 Public Database 

• Design and implement a robust and scaleable database to serve as the central repository for 
approximately 1.5 million records. (See entity relationship diagram in Architecture section of 
proposal) 

• Design overall functionality with 'ease of use' as a primary objective. This includes the use of 
intuitive screens, drop down menus, point and click buttons, and, where possible, maps or other 
illustrative mechanisms for areas such as selection of geographic preferences. 

• Provide for publication of Public Works (City/State/Federal) projects, which by definition are open 
to anyone and everyone, that qualifies to bid. 

• Provide segmentation of the 1.5 million records across the following categories. 

• Owners 

• Architects & Engineers 

• General Contractors 

• Subcontractors 
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• Blueprinters 

• Suppliers & Wholesalers 

• Building Product Manufacturers 

• Other Stakeholder Groups as Required 

• Provide segmentation for General Contractors and Subcontractors to self-select into one or more 
Uniform Construction Index (UCI) /Construction Services Institute (CSI) codes. The seventeen 
major UCI/CSI codes are listed below. The complete set of sub-codes inside each of these 
seventeen major codes are on file. 



01 


General Requirements 


02 


Sitework 


03 


Concrete 


04 


Masonry 


05 


Metals 


06 


Wood 


07 


Thermal 


08 


Doors 


09 


Finishes 


10 


Specialties 


11 


Equipment 


12 


Appliances 


13 


Pre Engineered Buildings 


14 


Conveying 


15 


Mechanical 


16 


Electrical 


17 


User Defined 



Provide the capability for user defined UCI/ CSI codes for both the public database and private 
portals. 

Provide a three level database service for all stakeholder groups, most notably Subcontractors, that 
comprise over half of the total population. The three levels are as follows: 

01 Bronze - A free database listing of approximately 20-25 data fields that includes: 

Company Name 
Work phone 
Contact 1 
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Contact 2 

Work fax 

Mobile phone 

Pager 

E-Mail 

Web Site 

Address 1 

Address 2 

City 

State 

Zip Code 

Bid Range - Min/Max 

Labor (Union, Open Shop, Open Shop/Prevailing Wage) 

Special Category (Minority, Women, Disadvantaged, Veteran) 

Trades (UCI/CSI) 

Geographic Preference 

Work Type (eg, Schools, Industrial, Retail) 

Trade Cross-Reference (Associate master UCI/CSI with self-defined) 
User Fields (5) 

02 Silver- A pay level 1 (fee TBD) of additional information that will enable automated due- 
diligence to be performed. The silver listing data fields include: 

Bonding & Insurance Information (Capacity, Agent, Rating) 

Annual sales volume 

Number of employees 

Officer contacts (3) 

Marketing contacts (2) 

Financial contacts (2) 

Field contacts (2) 

Emergency contacts (3) 

Credit History 

Project References (TBD) 

Business References (5) 

Convex Rating (TBD) 

03 Gold — A pay level 2 (fee TBD) whereby Convex will develop custom web pages for 
individual subscribers. 



• Provide full public database search capabilities on all data fields listed above. 
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• Provide an inverse load when General Contractors are selecting potential subcontractors from the 
public database so that Gold members appear at the top of the search results, followed by Silver 
members, then Bronze. This inverse load will be required for both full searches and segmented 
searches (eg, geographic location). 

• Prevent the downloading of the public database to protect against copyright infringements. 



2.3 Private Portals 



• Provide secure private portals for stakeholders, particularly General Contractors for the purpose of 
effectively and efficiently managing individual bids (projects) and subcontractors. Security will be 
developed through use of User ID's and passwords. 

• Provide General Contractors with the following functionality inside their private portals. 

• Ability to electronically receive new bids (projects) from Architects using Bid Manager. 

• Ability to organize bid by different bid types. The 5 primary bid types are as follows. 

• Public Works 

• Private Competitive 

• Negotiated 

• Design/Build 

• Re-Bid 

• Ability to create new projects for bids they will be responding to. 

• Ability to maintain inside their private portal a directory of their preferred subcontractors. 

• Ability to search the public database and populate their private portal with additional subcontractors 
they wish to add to their private directory. 

• Ability to search their private portal with the same multi-dimensional search capabilities 

• Ability to select UCI/ CSI codes for various bid components. 
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• Ability to match subcontractors with respective UCI/CSI codes and build lists of multiple 
subcontractors to individual codes to ensure adequate bid coverage. 

• Ability to create new codes outside of the standard UCI/ CSI master set. 

• Ability to electronically submit Invitations to Bid to the selected subcontractors for each project. 

• Ability to electronically receive bids from subcontractors. 

• Ability to electronically submit bid responses to architects. 

• Ability to create and electronically submit and receive additional supporting documents related to 
individual projects. These documents include: 

• Addenda- High priority items that include information direcdy related to individual projects 
that require immediate attention. 

• Scope Memos - Documents that signify some alteration to the original project. 

• Request For Information - Documents sent to various stakeholders that ask for clarification 
or additional information. 

• General Memos - Documents of a general nature that may be related to individual projects 
or to more generic topics. 

• Bid Withdrawal Form - Document that indicate that either a General Contractor or 
Subcontractor is withdrawing from the bid process. 

• Other — Additional document types may be defined as the development of Phase 1 
progresses. 

• Provide an easy to use and flexible directory/ folder based capability for organizing and managing 
projects and associated documents. 

• Provide an import mechanism from the public database to individual private portals for the purpose 
of populating private portals with new subcontractors or refreshing data on existing subcontractors 
already included in the private portal 
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Provide private portals with the ability to create new subcontractors independent of the public 
database to accommodate general contractors who use subcontractors that do not participate in the 
public database. 



Provide a variety of templates for the processing of projects and supporting documents. The 
required templates include the following. 

• Project Initiation- This template will be used by Architects and General Contractors to create 
a new project based on receipt of an individual bid package. Information will include, but 
may not be limited to the following: 

• Project ID 

• Project Title 

• Location 

• Bid Date and Time 

• Owner Information 

• Architect Information 

• Consultant Information 

• General Contractor Bidding Information 

• Project Type (25) 

• Estimated Valuation 

• General Scope of Work Description (Text) 

• UCI/CSI List of Trades (Or Key Word Index) 

• Standard Bid Response Form - A standardized template for Subcontractors to respond to 
individual bids. This template will use the Project Initiation template as the basis and 
additional data fields will include, but may not be limited to: 

• Subcontractor ID 

• Subcontractor Name 

• UCI/CSI Bid Coverage 

• Total Bid $ 

• Additional templates will be required for each of the following items to enable ease of use 
and consistency of data entry. Again, the data fields included in the Project Initiation 
template will be used as the starting point for each template. A general text section will be 
included in each template. 
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• Addenda 

• Scope 

• Request For Information 

• General Memos 

• Bid Withdrawal 

• Other - Additional document types may be defined as the development of Phase 1 progresses. As 
such, it may be determined that templates for these other documents may be required. 

2.4 Registration 

• Provide all participants with an easy to use initial registration process that includes a User ID and 
initial password. 

• Prevent participants from logging on to the system until they have completed the initial registration 
process. 

• Provide 'point and click', drop down pick lists, and other methods to facilitate ease of data entry. 

• Use a phased registration process that provides the free Bronze Listing registration process and 
follow that with a marketing prompt to illicit interest in the Silver and Gold subscription services. 

• Provide on-line credit card capability for participants registering for subscription services. 

• Provide an initial e-mail and/or fax to all participants upon initial registration welcoming them to the 
site. 

• Provide an e-mail and/or fax to the participant signing up for Gold Listing that a Convex 
representative will be contacting them regarding their web page. Additionally, provide an e-mail to 
the appropriate Convex representative that a new Gold Listing member has signed up. 

• Provide for automatic renewal of annual subscription services. 
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• Ensure that all participants have a system authorized User ID and password. 

• Ensure that a simple, easy to use and maintain process is in place for users needing User ID or 
password assistance. If feasible, an on line system prompt could be utilized. If this proves 
unworkable, Convex will need to consider this requirement as part of its on-going system 
maintenance process. 

2.6 Initial Database Population 

The public database will initially be populated using a combination of electronic upload from one or 
more industry listings and manual data entry. All stakeholders will be entered into the database with all 
relevant and available data fields populated. It is highly likely that the manual data cleanup and entry will 
be performed offshore. As such, close coordination between the Phase 1 Project Team and the offshore 
entity performing this task will be required. The Project Team will be responsible for providing database 
design layouts and, ultimately, access to the actual database once it is created. Sample data sheets should 
be fed into the database early in the process to ensure that the data being entered is consistent with the 
overall database design. As such, the master data set for the public domain will be, in all likelihood, built 
using an iterative process. 

Upon completion of the master public database, and upon implementation of the Phase 1 system, it is 
proposed that a one-time e-mail and fax activity be conducted that will notify each of the database entries 
about the implementation of Bid Manager. A marketing piece will be incorporated into this notification 
and individuals will be encouraged to visit the site and register. The possibility of developing system 
generated User ID's and passwords will be explored. The notification process could be repeated if 
desired. 
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3.0 Preliminary System Recommendations 

3.1 Graphical User Interface 

This section deals with the approach to be used for the design and development of the Graphical User 
Interface (GUI) and also presents a high level workflow of web pages. Four sample Bid Manager home 
pages are also included for review and input. 

Our overall objective with respect to the user interface is to build a persuasive IT solution for Convex 
and its user population. We will use rational and emotional techniques to move users to know, feel and 
do what it takes to deliver business results to the client. We bring to each project: 

• Insight and intuition to the heart and mind of the user 

• Big Ideas 

• Objective excellence in design and copy execution 

• Functional form 

• Leverage of Brand equity 

The creative process takes place in the span of 3 to 5 weeks. It starts with the sign off of a creative brief 
that outlines the goals and objectives of the project, as well as the functionality matrix documents which 
defines all the functionality and content that the site will contain. 

The first step is the information architecture (page flow) development. This phase usually occurs during 
the first week. Some initial work has already been completed in this area. The page flow will enable the 
designer to establish persistent, primary and secondary navigation. This is also important in determining 
how certain areas within each page will need to be graphically treated by placing the right emphasis on 
the most relevant information. 

After the page flow and the overall home page concept have been approved, the designers will start to 
develop more detailed designs for the site. Additional key pages will be developed in a static format 
(only graphics, no HTML), this initial design development takes place in approximately 10 days. 

At the end of the 1 0 days, we will formally present 2 to 3 additional design concepts for review and 
feedback. Once the final design direction is selected, the second phase of creative will take place. At this 
point the feedback from the initial design presentation will be incorporated into the selected design as 
well as all other changes pertaining to functionality and navigation requirements. This step is usually 
performed in a week, depending on the amount of changes being performed. At this point a second 
formal presentation will take place to review the revised creative. If additional feedback is received, one 
more week or more, depending on amount of changes, will be added to the creative cycle to incorporate 
all these additional changes. 
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A third and final presentation will take place to ensure that all changes from previous meeting have been 
incorporated. If no additional changes are required, the final creative will be signed off. 

High Level Flow 
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Sample Bid Manager Home Pages 

On the following four pages, sample Bid Manager Home Pages are included for review and input. 
These pages have been designed based on discussions conducted during the Requirements Week as 
well as additional dialogue that has taken place since that time. 



i Back 



a c % g§ m % © 

Home Refresh Open Print Search : ■:; 




WELCOME! 



We are a pre-construction services site that enables 
commercial construction communities to participate 
in more efficient and cost effective bidding practices. 
Currently 160,000 projects being bid on this site! 



To find out more about how we can specifically help 
you cut your bidding time in half, click on your specific 
areas on the menu to the left for a preview of some of 
the great features this site has to offer! 
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i Back Home Refresh Open Print Search 



(^Live Home Page Apple Computer ^ ; Apple Support ^ Apple Store <§fc.MSN (^Office for Macintosh Internet E: 



CONVEX 



architect 
& engineers 

general 
contractors 

subcontractors 

suppliers & 
wholesalers 

building product 
manufacturers 



register 
log-in 



WELCOME! 

We are a pre-construction services site that enables 
commercial construction communities to participate 
in more efficient and cost effective bidding practices. 
Currently 160,000 projects being bid on this site! 

T o find out more about how we can specifically help you cut 
your bidding time m naif click on your specific areas on the 
mem; to the left for a pie view of some of the great featuies 
tins site has to offer' 
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^ architect 
& engineers 

> general 
contractors 

I subcontractors 

\ suppliers & 
wholesalers 

\ building product 
manufacturers 



WELCOME! 

We are a pre-construction services site that enables 
commercial construction communities to participate 
in more efficient and cost effective bidding practices. 
Currently 160,000 projects being bid on this site! 

To find out more about how we can specifically help 
you cut your bidding time in half, click on your specific 
areas on the menu to the left for a preview of some of 
the great features this site has to offer! 
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£ OWNER 

0 ARCHITECT 
& ENGINEERS 

0 GENERAL 

CONTRACTORS 

0 SUBCONTRACTORS 

£ SUPPLIERS & 
WHOLESALERS 

# BUILDING PRODUCT 
MANUFACTURERS 



WELCOME! 

We are a pre-construction services site that enables 
commercial construction communities to participate 
in more efficient and cost effective bidding practices. 
Currently 160,000 projects being bid on this site! 

To find out more about how we can specifically help 
you cut your bidding time in half, click on your specific 
areas on the menu to the left for a preview of some of 
the great features this site has to offer! 
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The diagram atewe illustrates the object hierarchy that relates to the system domain functionality. It 
depicts the types of objects (called classes of objects) in the system. There would, of course, be multiple 
instances of many of the objects. This diagram shows what is called the object inheritance relationships. 
For example, a General Contractor object is a type of Company object, which in turn is a type of Entity 
object. The General Contractor is said to inherit from the Company object. This means that the 
Company object will have certain data and functionality that will be available to all of its subclasses, such 
as General Contractor. In this manner, a specific piece of functionality will only show up once in the 
system but will be shared by all objects that need to use it. In addition to the objects shown here, there 
will be several significant utility objects, such as e-mail and fax objects. 

Please note that the majority of the hierarchy is taken up by documents and companies. 

3.2.1.2 General Contractor 
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This diagram above uses a General Contractor (G.C) as an example of how a primary actor object 
functions. In contrast to the object hierarchy, which shows static relationships, this diagram illustrates 
dynamic relationships at runtime. It shows all of the ob|CCts that a G.C. would be connected to. Note 
that there is no connection between a G.C. and the public list of Subcontractors (S.C.s). Page logic 
would allow a G.C. user to take company listings out of the public list and put them into the G.C.'s 
private list, or into a specific G.C. project. 

3.2.1.3 Security Object Relationships 

This diagram below shows how the three objects used for security interact. The Company objects would 
be replaced in the real world with instances of specific sub-classes, such as G.C. and S.C. objects. 




3.2.2 Object Descriptions 



Object Name 


Description 


Knows About 


Addendum 


This document contains information 
relating to official changes in the bid. 


No other objects 




Object Name 


Description 


Knows About 


Architect 


This primary actor has information and 
functionality specific to an Architecture 
company. 


Its private list of G.C.s 
Its list of projects 
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| Object Name 


Description 


Knows About 


Category 


This is a List that has a name associated 
with it. It can function in a variety of 
settings like a folder or directory does in an 
operating system. 


Its contents 






Object Name 


Description 


Knows About 


Classification 


This contains the basic qualities of a 
reference to a particular item, such as a 
code and a description. 


No other objects 




Object Name 


Description 


Knows About 


Company 


This represents a registered company in the 
system, and has the ability to store private 
lists of company listings, and to massage 
them into smaller sets. 


Its corresponding 
Company Listing. 
Its private list of 
companies. 




Object Name 


Description 


Knows About 


Company Listing 


This records the most basic information on 
a company for all registered and 
unregistered companies. 


Its corresponding 
specific type of 
company object if this 
company is registered. 




Object Name 


Description 


Knows About 


Correspondence 


This is a general piece of correspondence. 


No other objects 




Object Name 


Description 


Knows About 


Document 


This is an abstract class that represents the 
most basic qualities of all documents in the 
system. 


No other objects 




Object Name 


Description 


Knows About 


Engineer 


This primary actor has information and 
functionality specific to an Engineering 
company. 


Its private list of G.C.s 
Its list of projects. 




Object Name 


Description 


Knows About 1 


Entity 


This is an abstract class that represents a 


Any sub entities that it 




user of the system, or an agregrate of users. 


contains 
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Object Name 


Description 


Knows About 


Feedback 


This is a document used in the customer 
satisfaction section of the system. 


No other objects 




Object Name 


Description 


Knows About 


General 
Contractor 


This primary actor has information and 
functionality specific to a General 
Contractor company. 


Its private list of S.C.s 
Its list of projects. 



Object Name 


Description 


Knows About 


Geographical 


This refers to a geographical location, such 
as a county or state. 


No other objects 



Object Name 


Description 


Knows About 


Group 


This is an aggregation of users of the 


No other objects 




system for the purposes of security and 






sharing of information. A group may 






represent a department or office in a larger 






company. 





Object Name 


Description 


Knows About 


Invitation To Bid 


This is a document that details an invitation 
to certain parties to bid on a project. 


No other objects 



Object Name 


Description 


Knows About 


List 


This has the ability to contain an ordered 


Its contents 




set of other objects. 






Object Name 


Description 


Knows About 


Material 


This refers to a particular building material. 


No other objects 




Object Name 


Description 


Knows About 


News Article 


This document contains news information. 


No other objects 




This could be project or industry news. 




Object Name 


Description 


Knows About 


Object 


This is an abstract object that is the root of 


No other objects 




all other objects in the system. It contains 
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the basic qualities that make an object an 
object. 






Object Name 


Description 


Knows About 


Owner 


This primary actor has information and 
functionality specific to an Engineering 
company. 


Its list of projects 




Object Name 


Description 


Knows About 


Plan 


This unstructured document represents the 
basic plan for a project. 


No other objects 






Object Name 


Description 


Knows About 


Project 


This abstract class organizes the basic data 
and functionality of a project. This takes the 
trade classifications and company listings 
that they contain and uses them to send out 
documents to lists of recipients. 


Its correspondence. 
Its trade classifications, 
each of which contains 
company listings. 




Object Name 


Description 


Knows About 


Project - Architect 


This project type will be created 
automatically for all projects when the 


Its list of G.C.s that are 
invited to bid, those 




initiating company is an Architect. 


that bid, and the G.C. 
that is handling the 
project. 




Object Name 


Description 


Knows About 


Project - G. C. 


This project type will be created 
automatically for all projects when the 


Its list of S.C.s that are 
invited to bid, those 




initiating company is a General Contractor. 


that bid, and those that 
are handling the 
project. 




Object Name 


Description 


Knows About 


Project - S. C. 


This project type will be created 
automatically for all projects when the 


Its list of S.C.s that are 
invited to bid, those 




initiating company is a Subcontractor. 


that bid, and those that 
are handling the 
project. 
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1 Object Name 


Description 


Knows About 


RFI 


This document represents a request for 
information that is passed from an S.C. to a 
G.C. or from a G.C to an Architect or 
Engineer. 


No other objects 




1 Object Name 


Description 


Knows About 


Scope Memo 


This document represents an unofficial 
change, or a suggested approach to a 
project. 


No other objects 




Object Name 


Description 


Knows About 


Specification 


This unstructured document represents the 
detailed specifications of a project. 


No other objects 




Object Name 


Description 


Knows About 


Structured 
Document 


This is an abstract class that represents a 
document that has known internal fields. 
This is based on one of the basic templates 
of the system. 


No other objects 




Object Name 


Description 


Knows About 


Subcontractor 


This primary actor has information and 
functionality specific to a Subcontractor 
company. 


Its private list of S.C.s 
Its list of projects. 
Its list of CSI / 
geographical codes 
indicating work that 
will be accepted. 




Object Name 


Description 


Knows About 


Supplier / BPM / 
Blue Printer 


This represents a registered company that 
doesn't need to store special information. 


No other objects 




Object Name 


Description 


Knows About 


Trade 


This refers to a particular building trade, 
such as a CSI code. 


No other objects 
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Unstructured 
Document 



This is an abstract class that represents a 
document that has no known internal 
structure, such as a steam of characters or a 
binary file. 



No other objects 




User 



This represents a user of the system. A 
user will always belong to a company. He 
or she may also belong to one or more 



No other objects. 
Thus, this can't have 
sub-entities. 



groups. 



3.2.3 Web Server Considerations 

At a high level the system has the following requirements and characteristics: 

■ The ability of the system to provide web pages quickly in response to user requests is critical. 

■ Availability of the system to users all day every day is critical. 

■ The web site will eventually have large numbers of users. 

■ The web pages are not overly complex or technically challenging. 

■ There are no legacy systems involved. 

■ There is only one backend database. 

■ One of the major responsibilities of the system is to send messages - emails and faxes. 

This indicates the need for a Web Application Server coupled with a message oriented middleware such 
as MQSeries. The sections that follow elaborate on the choices in this arena. 

3.2.4 Defining a Web Application Server 

At a basic level, a Web application server is a strategic platform used to rapidly develop, deploy, and 
manage Web-based application logic that integrates existing legacy and client/server systems. What 
differentiates these products most notably from other traditional application servers is that the clients 
connecting to these new mid-tier servers are typically Web browsers or "thin" versus "fat" clients that 
store application code and data locally. Most Web application servers todav support development and 

A*.n\n, mar *v ~C \ *U Jr. .. . . . r . . . r 



deployment of both C++ and Java, as well as some other proprietary tools and scripting languages. More 
importandy, these servers support Web technologies and standards such as Java, ActiveX, HTTP, HOP, 
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CORBA, COM/DCOM, EJB, ODBC, JDBC, SSL, digital certificates, and LDAP to enhance distributed 
server-to-client and server-to-server sessions. 



There are Jive characteristics of Web Application servers: 

1 • Performance: Load balancing and server fail-over route Web users to the best available server. 
Thread pooling and object caching optimize server resources. A scalable transaction service ensures 
reliable database updates. 

2. Connectivity: App servers provide and object request broker and connection services to packaged 
apps, middleware services and databases. Database connections get pooled and cached for speed. 

3. Application: App management includes standard features like software upgrading and exception 
notification. But it also covers on-line performance tuning of individual code components in a 
complex, mutli-server configuration. 

4. Ease of development: App servers must support best of breed tools to address team development, 
distribution debugging and an array of in-house technical skills. The goal is to blend hard core coding 
with drag and drop simplicity. 

5. Transactive Content Support: App Server vendors must provide a clear path to integration with 
the content catalogs, personalization and collaboration services that engender a self-service 
experience. 



The diagram below illustrates the various components that are required for robust web architecture. 



User Interface 



Web 
Server(s) 



Web 
Application 
Server 
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Business Rules/Logic 
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The most scalable and flexible application servers for the Web are those that support multiple platforms, 
are compatible with many different development tools, and provide robust high volume transactional and 
object model support. Other distinguishing features may include persistent memory caching, 
transactional isolation and recovery, database connection pooling, transaction multi-threading, event 
handling, state management, the ability to roll back and isolate transactions, middleware support, ERP 
integration, security and directory support, and object model support. High-end Web application servers 
are used for business-critical systems that require 24 x 7 up-time and high-grade performance. 

3.2.5 Application Server Market Leaders 

The following vendors currently play in this market. The grid illustrates the features and capabilities of 
each. During the design phase of the project the decision to move forward with a particular application 
server will be verified based on the characteristics of the application. However, based on our current 
understanding of the business requirements, we feel that the recommended technical components 
described later in this section will be validated as the most appropriate technical choices. 

Application Server Backgrounds 



IBM: 

WebSphere 

Netscape 

Application 

Server 

Microsoft 
MTS 



Oracle 

Application 

Server 
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1. IBM WebSphere: A well-engineered engine with good scaling potential. But IBM must offer 
simpler tools and clarify the landscape of WebSphere, Domino and Component Broker. 

2. Microsoft MTS: Microsoft's platform scalability hampers for large corporate sites. Although there 
are a few notable companies such as DELL and 1 -800-Flowers have successfully deployed large-scale 
sites. Its well-integrated HTML and COM strategy boosts the platform's ability to deliver self-service 
applications. 

3. Netscape Application Server: Netscape's Kiva acquisition locked in it lead in Web based 
transaction performance. 

4. Oracle Application Server: Tight integration with Oracle 8 makes existing customers happy but 
limits options for portability and connectivity. 

5. Sun's NetDynamics: Offers good connectivity but runs out of gas in large deployments. The 
products integrated tool is productive but too proprietary. 

♦Note: NetScape and Sun have publicly announced an aggressive plan to integrate the "best" 
features of their respective application servers within one year. It is highly likely that the resulting 
server will be backward compatible to both NAS and NetDynamics. By selecting either of these 
servers, one is likely to have a straightforward migration path to their next-generation application 
server and gain the best features of each. Furthermore, the server will likely be "tuned" for highest 
performance on Sun Servers. 

3.2.6 Technical Components 

Navigating the many vendors, product offerings, and technical acronyms in this market is challenging. 
Solutions vary considerably by vendor and each excels in a specific area, whether it is manageability, 
integrated development and deployment, object support, platform support, or advanced transactional 
support. Few vendors today offer a comprehensive solution. 

Specifically, for this application vendor products were evaluated with the following criteria in mind: 

• Scalability, 

• Transaction-handling and connection/pooling services, 

• Manageability and load balancing, 

• Security features and access control, 

• Integrated development environment, 

• Object model support, 
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Netscape Application Server (NAS) began as an exercise in load balancing, fault tolerance, and scalability. 
It is generally recognized as being the best in these areas. Netscape has ignored development tools in 
shaping its offering, but the quality of its tools has improved. It is also possible to use third party tools, 
although this is complicated by the fact that Netscape uses custom HTML tags to link web pages to 
business logic. 

Based upon this, NAS currently looks like the best choice for a Web Application Server. 

Web Application Servers frequendy use middleware to pass data in a guaranteed way to and from their 
backend systems, such as databases. There are two main choices here. One is a transaction monitor, 
also referred to these days as object monitors. The other is messaging middleware. It is also possible to 
use a combination of the two 

Transaction monitors guarantee the delivery of data, and orchestrate groups of data messages (called a 
transaction), guaranteeing that the entire group will be passed or if there is an error, that all systems will 
be informed and that no data will be passed. Thus there can't be partially completed transactions. If the 
intent is to transfer money from one account to another, it's not possible to remove money from one 
account unless it also is added to the other. Transaction monitors tend to be synchronous - all the 
involved systems must be online at the same time, and resources wait until the transaction is finished. 

Messaging middleware guarantees the delivery of data by using a feature called "store and forward". 
Data is placed in a queue and then an attempt is made to deliver the data to its destination. If it can't be 
delivered at the present time, it tries again later. It is an asynchronous arrangement. All systems are not 
required to be online at the same time. If a system is down, delivery is still guaranteed, because the 
message will be delivered when the system comes back online later. This feature is also good for 
performance because resources don't have to wait for the delivery of the data. A system puts data into a 
message queue and then immediately continues, knowing that the data will be delivered eventually. 

We feel that the system will benefit more from using messaging middleware, such as IBM's MOSeries. 

Thus for Phase One, we recommend Netscape Application Server coupled with 
MQSeries to create the foundation upon which the infrastructure would be built. This 
recommendation will be validated during Bid Manage/ s design phase. 
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3.3 Back-end Systems 
Database 

We are proposing Oracle 81 as the database for Bid Manager. Recognized throughout the industry as the 
database of choice for large-scale web systems, Oracle provides the both the functionality and scalability 
required for Convex. Additionally, we are proposing Sun servers for the application layers. During the 
Requirements Week, some discussion regarding the possible use of Dell servers in some capacity was 
discussed. This possibility needs to be further explored during the Design phase. 

Fax Technology 

Preliminary analysis has led us to three possible technology solutions for the fax requirements associated 
with Phase 1. These 3 possible solutions are as follows: 

1. 3 Com IP Fax Service 

2. UUfax 

3. Jfax 

All three of these products seem to offer the bandwidth required for the anticipated Bid Manager 
volumes. Additional research into these three products is ongoing and a recommendation will be made 
early on during the Design phase. 



We are not comfortable proposing an e-mail solution at this time. Additional research is on-going. 
The total hardware costs associated with Bid Manager Phase 1 will be finalized during the Design phase. 
Entity Relationship Diagram 

The initial entity relationship diagram required for Bid Manager Phase 1 is included at the end of this 
proposal as Attachment 1. 
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4.0 Approach and Methodology 

We propose that the project to develop the Bid Manager (Phase I) aspect of on-line construction 
portal for CONVEX Technologies, Inc., be undertaken in three phases. The first phase will be a 
Scope Phase, followed by a detailed Design Phase, followed by the Development Phase. 

The Scope phase will finalize the functionality that can be delivered by the October timeframe in 
addition to identifying high level functional features of Phase Two and Three. While focusing on 
Phase One, the Design Phase will finalize the detail of the required screen layout and supporting 
functionality, creating a detailed Business Design. In addition, the high-level technical design will be 
prepared, reviewed and approved with CONVEX Technologies. 

The Design Phase will also provide a revised estimate on the effort required to complete the 
Development Phase. The goal will be to deliver the revised estimate before the completion of the 
design, leaving enough time for the estimate to be approved by the design end date. This will allow 
the Development Phase to begin immediately after the Design Phase. This will be required to meet 
the target dates. 

The Development Phase will consist of two major types of activities, implementation and Testing. 
Implementation consists of coding and unit testing. Testing is broken out into Integration testing 
and System testing. Integration Testing is the process of integrating the separately developed 
modules, scripting the testing, executing the tests and fixing defects that are discovered. System 
Testing ensures the integrity of the overall system through a series of rigorous stress and 
performance testing. Once these activities are completed the system is ready to be rolled out. 

4.1 Scope Process 

4.1.1 Scope Process Overview 

"Scoping" is the method by which specific functional and technical aspects of an application are 
explored, defined and committed to by a cross-functional project team. It sets the scope of the 
application to be developed in specific and actionable terms. The goal of this effort is ensure that the 
scope of work for the Bid Manager is thoroughly understood. 

The Scope of Work document reflects a high-level functional and technical specification for the project in 
the context of your present IT architecture. It also will define the application for subsequent phases of 
the project. 

Through an iterative process the Scope of Work comes to represent the functional, creative, and 
technical aspects of the application. 
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Development of the Scope of Work often begins with a Functionality Matrix Workshop, which forces the 
team to evaluate and prioritize specific functional requirements of the application with an eye toward the 
costs, tangible and intangible benefits of each. 

The Functionality Matrix is used, as a tool to define what functionality is needed for a given application. It 
is a grid of cells collected into rows, each of which contains a grouping of closely related tasks, which 
need to be developed together. Its purpose is to succinctly display the grouping and prioritization of 
functionality discussed during the project. 

The matrix has both row and column headings (alpha and numeric, respectively). From left to right are 
the most important to least important functions. A solid line indicates which functionality will be 
included in this project phase - that is, cells to the left of the solid line are within scope. The cells 
appearing to the right of the solid line indicate functionality that would be implemented in a future phase. 
Additionally, light shading has been used to identify functionality that is not currently in scope but would 
be nice to have. 

A cell is a set of functionality that must be developed in its entirety to have an important impact on your 
business. This doesn't necessarily mean that a cell cannot be broken down further into smaller pieces. Each cell 
represents a distinct, implementable group of actions, often determined partially by a business process 
flow. The functionality matrix shown below was developed for one of our previous clients, however 
indicates the depth of this exercise. 

The importance of this exercise cannot be overemphasized. It ensures that all the participants share a 
common vision of not only what the team is doing, but also why they are doing it. Failure to achieve this 
consensus before work begins is a primary cause of failure among e-Business development efforts. An 
example of a Functionality Matrix is included at the end of this proposal as Attachment B. • 
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4.2 Design Phase 

4.2.1 Design Process Overview 




Overview of Design Process 

The figure above identifies the activities proposed for the Design Phase. The detailed functionality will 
be clarified through a short series of user meetings. In parallel with these meetings a mock up of the user 
interface will be provided to aid in the evaluation of the detailed functionality. CONVEX Technologies 
will then verify the functionality at the checkpoint. Technical design and revision of the development 
plan will continue in parallel. The technical design sections will describe the architecture for Phase One, 
identify the required software modules, each module's function, and the interfaces between modules. The 
architecture will be designed taking into consideration the high level requirements for the follow-on 
phases. 

4.2.2 Functional Design 

Functional Design refines the functionality into a viable user interface, and defines the relationship 
between the user interface and the backend systems. Functional and User Interface Design is iterative in 
nature. We suggest a total of seven working days duration for this activity. In Functional and User 
Interface Design the following will be refined with CONVEX Technologies: 

• The process flow, 

• The screen flow, 

• The functionality and layout of the screens, and 

• The data required from the backend systems 

To allow the design to proceed effectively individuals to fill the following part time roles need to be 
provided by CONVEX Technologies, Inc.: 
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• User expert (to provide input on the content, flow and acceptability of the proposed user interface) 

• Business Process Expert (to provide data on the required business flow for Phase One) 

The maximum time spent on user meedngs will be five hours per day. Not all the roles will be required 
for all the meetings. A detailed meeting schedule will be agreed between CONVEX Technologies and 
Primix/E-Logical prior to the start of the Design Phase. 

4.2.3 Interface Simulation 

An HTML-based Interface Simulation is developed to represent the interface of the finished application, as 
it will appear to one or more targeted end users. 

Pnmix has learned that the use of these simulations early in the development process serves two ends. 
First, it makes the application "real" to executive management inside the client organization, which aligns 
expectation of the project's end product and solidifies support for the project itself. Second, it allows the 
Project Team to solicit feedback from targeted end-users in a very natural way, and to incorporate that 
feedback into the design of the application. This simple but often overlooked technique improves 
adoption of the finished application, increasingly the likelihood of delivering business results. 

4.2.4 Validate Overall Architecture 

After the functional requirements are detailed, the proposed architecture will be reviewed to ensure that 
the architecture still meets the revised requirements. Given that the functionality is already well defined in 
most areas Primix believes that this will be a short task, but necessary to mitigate the risk of a costly 
mistake in the architecture definition. 

4.2.5 Checkpoint 

The detailed functionality will be documented in the relevant sections of the design document. These 
sections, as well as the section documenting the architecture, and the mock up will be given to 
CONVEX for review. It is our preference that a review meeting should be held within three business 
days of the draft being provided. We will then address any comments that arise from the review process, 
and will incorporate any changes into the final complete document, which will be produced at the end of 
the technical design activitv. 
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4.2.6 Technical Design 

The Technical Design Phase moves from the architecture validated during the functional design activity 
to a module level breakdown of the proposed components: 

• Customization of dynamic HTML templates, 

• Static HTML for the Web server. 

For each module identified the following information will be provided in the completed design 
document: 

• Module name and description, 

• Required behavior for the module, 

• Module interface to the rest of the Bid Manager applicadon. 

During the Technical Design Phase interacdon with the user community is normally carried out on an as 
required basis to resolve issues and questions that arise during the design process. The dme required 
from users to deal with the issues that arise is typically insignificant. 

We would like to provide an informal technical meeting on a weekly basis. The purpose of the meeting 
would be for the Design team to discuss the progress of the design activity, and to oudine any major 
design decisions made. In our experience this is an efficient way to broaden understanding of the project 
within a client organization. 

4.2.7 Revise Development Project Plan 

A stcp-by-step Project Plan is also produced during Design. The plan defines key milestones for the 
project, identifies the critical path of development, and states the level and depth of resources required 
during each week of the project. 

There is no more powerful evidence of our belief in the power of strategic preparation and detailed 
planning to manage the development risks of a project than our willingness to commit to a fixed- 
price/ fixed-time bid for Development at this point in the process. 

From this point, the launch date and budget for the project are locked. Barring changes in scope you 
believe arc necessary during implementation, we guarantee the timing and expense of the project from 
this point, with our fixed development bid. 
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4.2.8 Review Design Document 

After the technical design activity has been completed there will be a short time to complete the design 
document. The design document will be provided to CONVEX for review. It is our preference that a 
review meeting should be held within three business days of the draft being provided. The review 
process will only address the sections that have been added since the checkpoint reviewed the required 
functionality. We will incorporate any changes into a revised version of the Design Document which will 
be provided for CONVEX approval as soon as possible after the review process has been completed. 

4.3 Development Phase 

4.3.1 Development Process Overview 

The goal of the Development is to build and test the solution specified in the Design STEP. 

The primary Development deliverable is, of course, the application itself. Additional deliverables are 
tailored to individual customer requirements. These may include solution code, an updated Design 
document, an installation guide, a user guide, and a system administration guide. 

Tasks within the Development include: 

• Building all user interfaces, functionality, data schema, integration and connectivity required for the 

solution 

• Connecting user interfaces to functional layers and test data 

• Configuring and testing hardware and networking infrastructures 

• Performing integration testing of the solution components 

• Performing system testing of the completed solution 

• Conducting end-user acceptance testing to reaffirm that the solution meets the specified 

requirements 

Primix has a unit testing methodology that requires the implementer to identify the types of unit testing 
that they propose for a given module. The senior technical member of the functional team reviews the 
proposed tests. This ensures comprehensive unit testing. 

Samples of the code are also reviewed by peers and by senior technical members of the team. These 
code reviews are used especially at the start of the implementation process to ensure that standards are 
being followed, and good coding practices are being used. 
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4.3.2 Integration Testing 

Integration testing of the Bid Manager will concentrate on verifying the integrity of the design and 
internal interfaces, and a significant portion will be carried out in parallel with the implementation 
activity. 

An integration test plan will be produced before integration testing begins. This will outline the testing 
to be carried out and any data needs. It is proposed that integration be performed incrementally. This 
means that the production of modules from the different functional areas will be coordinated so that 
they can be integrated and tested as a stand-alone function. There is not currently enough information 
available to provide a detailed plan for integration at this stage. The detailed plan will be provided during 
the Design Phase. 

As defects are discovered during testing, they will be prioritized and passed to the development team to 
fix. 

It has not been verified with CONVEX what criteria are typically applied to validate that an application 
has successfully completed integration testing. For estimation purposes Primix have applied our 
standard criteria that 95% of tests are executed and no critical level defects are open. 

4.3.3 System Testing 

The activities that Primix considers part of System Testing 

• Execution of test scripts in a formal system test environment 

• Performance testing 

• Volume Testing 

4.3.4 Deployment 

In the Deployment STEP, we deploy the fully developed and tested solution into your production 
environment. We have found that each client has special requirements for solution deployment and 
therefore we arc very flexible in defining Deployment STEP deliverables. During this step, Primix 
ensures that the solution is stable and providing business value to your company, customers or business 
partners. Because of the need to provide reliable service we may need to investigate the possibilities of 
hosting this application with an application hosting party such as Exodus, Digex etc. 
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5.0 Project Plan 

5.1.1 Schedule 

The Scope runs from a proposed start date of 7/19/99 to 7/23/99. The outcome of this week would be 
the functionality matrix and consensus regarding the features and functionality if Phase One that we can 
deliver by the desired date. The design phase will begin on 7/26/99 immediately following the scoping 
session. We are allocating 5 weeks for design however will attempt to complete this in 4 weeks. In order 
to meet the aggressive overall timeframe it is suggested that the revised development plan be delivered bv 
8/20/99. 

The Project design team will work at the CONVEX Technologies site for the UI Design Phase. We 
anticipate that the entire design team will require six (6) consultants. 

5.1.2 Milestones 

Milestones are key points in a project where demonstrable progress can be seen. The suggested 
milestones for the Scope & Design Phase are given in the following table. 



Milestone 


Date Due 


Scope Start 


7/19/99 


Scope Completion with Functionality Matrix 


7/23/99 


Design Start 


7/26/99 


Delivery of functional sections for review 


7/13/99 


Delivery of Interface Simulation 


7/13/99 


Delivery of revised development plan 


8/20/99 


Delivery completed design for review 


8/27/99 



5.1.3 Deliverables 

There are three deliverables to CONVEX Technologies at the end of the Design Phase. These are the 
Design Document, the mock up (Interface Simulation), and a revised development plan. 

The Design Document will be delivered in two installments. The first installment will consist of the 
functional sections. A mock up of the screens will also be delivered. Together the first sections and the 
mock up comprise the functional baseline for the Phase One system. A complete Design Document will 
be delivered after the technical design. 

In addition a revised development plan will be provided to CONVEX. This will be a much more detailed 
version of section 5.2.2 Milestones for Development. 
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5.2 Development Phase Project Plan 

5.2.1 Schedule 

In essence, the development runs from a proposed start date of 9/6/99 to deliver}' of the system-tested 
application on 1 1 /26/99. 

5.2.2 Milestones 

The suggested milestones for the Development Phase are: 



Milestone 


Date Due 


Development Start 


9/7/99 


Software and Hardware Setup 


9/13/99 


Completion of Implementation 


11/5/99 


Completion of Integration testing 


11/12/98 


Completion of System Testing 


11/26/99 



The hardware requirements will be finalize two weeks from the official start date. It is expected that the 
hardware be available for the start of development. 
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6.0 Primix Solutions 

Primix Solutions brings strategic insight, creative talent and technical depth together to help clients solve 
problems, capitalize on new opportunities, and achieve business results online. 

Since 1994, we have delivered innovative e-Business solutions to our customers using best of breed 
technologies on a fixed-price/ fixed-time basis. We specialize in "through the enterprise" solutions that 
tie Internet-based applications - serving customers, staff, suppliers, business partner and distributors - to 
existing ERP and legacy systems. 



Primix has a track record of 
successful engagements in which we 
have helped our customers take 
advantage of information technology 
to establish closer relationships with 
their customers, suppliers, 
distributors, and employees. We have 
developed solutions for clients across 
many industries - Oil and Gas, 
Consumer Packaged Goods, 
Manufacturing, Financial Services and 
High Technology. 

In December 1998, Primix acquired Advis, a privately held Boston-based e-Business software consulting 
company, adding to its depth of capability in highly advanced Internet and object-oriented technologies. 

Our Vision 

Passion to Deliver Business Results. 

We know getting business results online is hard work. It takes strategic insight, creative talent, and 
technical depth. It takes experience. It takes discipline. It takes good people. 

Primix Solutions (Nasdaq: PMIX) brings all these together to deliver e-Business solutions that exceed 
customers' expectations. Our more than 100 professionals - with backgrounds in systems integration, 
management consulting, software development, advertising, and design - have done 
exacdy that for clients including AT&T, Apple, Gillette, Rockwell, Data General, ConAgra, Fannie Mae, 
Lucent and Standard & Poors. 

Our business is IT solutions. But our passion is business results. 



What Makes Primix Different? 

> Industrial strength systems integration skills 

- Power to execute, meet challenges, manage risk 

> Big Ideas 

- Strategic insight and creative talent 

> Passion for business results 

- Track record of client satisfaction 
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7.0 Primix Solutions and logical-E Qualifications 

CONVEX's Bid Manager is the initial phase of a three-phase project that will ultimately link the entire 
value-chain of the commercial construction market from project conceptualization through supply chain 
purchasing. Bid Manager functionality will provide a Pre-Construction Service Portal that will enable 
commercial construction communities to participate in more efficient and cost effective bidding 
practices. Delivery of a successful solution for Phase I will require expertise in a number of areas: 

• Complex Project Management Methodology to Support Technical Complexity and 
Time-to-Marlcet Urgency- CONVEX is entering a highly competitive marketplace. Rapid time 
to market is essential. Each phase of this project presents its own unique technical challenge and 
each subsequent phase will build upon its predessors. 

• Intuitive Graphical User Interface Design - CONVEX's target users are, on average, non- 
technical users with little or no PC experience. Bid Manager's GUI design must be completely 
intuitive to this target audience yet sufficiently powerful to provide full-featured functionality 
throughout the complex bid process. The page flow must also be designed to incorporate future 
functionality to be added during subsequent phases. 

• Web Architecture — The primary technical requirements for Bid Manager will be heavy messaging 
infrastructure, high-performance response times and extensible design. Phases II and III will require 
high-volume transaction capabilities and high-bandwidth. Bid Manager's architecture must be 
designed to support both immediate and future scalability, performance and robustness 
requirements. 

• DataBase Architecture - A primary component of Bid Manager is the ability to store 1 .5 million 
records. Furthermore, Phases II and III will require storage of blueprints for all of the projects as 
well as access to as many as one billion SKUs of Building Product Materials (BPMs). Thus, the 
database must be designed to handle significant extensibility 

The following examples of e-Business solutions delivered by Primix Solutions and logical-E demonstrate 
expertise in each of these respective disciplines:. 



7.1 Project Management Experience 

The ability to deliver large-scale, multi-phased projects under tight time constraints requires a strong 
methodology that drives tight project control and frequent deliverables. It also requires experience in 
working closely with the client's team to ensure effective communication and build consensus. Primix 
demonstrates this ability in all of its engagements but the following examples illustrate projects that were 
large in scale, multi-phased and required rapid delivery: 
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Rockwell Collins (Rockwell) 

Workforce Information Network (WIN) - Employee Self Service Application 

Rockwell Collins is a $2.4 billion business unit of Rockwell International and a global leader in the 
development of integrated aviation electronics systems for military and commercial aircraft. The 
company employs 14,000 people in the U.S. and abroad and leads the aviation industry in the 
development of communication, navigation, surveillance and situational awareness technologies. 

Rockwell had selected SAP R/3 to manage a wide range of strategic business processes. A Web based 
employee self-service (ESS) solution known as WIN was planned to leverage the standard functionality 
provided in SAP to enable employees to obtain and update information through the corporate Intranet. 
Rockwell defined the solution as "critical path" due to Government auditor's time-entry requirements so 
that the 18-month R/3 implementation could not go-live until WIN was completed. This fact was 
realized well into the SAP implementation resulting in a hard delivery requirement of just 13 weeks for 
Design and Development of WIN. 

After a thorough evaluation of potential System Integrators, including D&T and SAP, Rockwell Collins 
selected Primix Solutions to deliver WIN. Primix built the solution using its fixed-price/ fixed- time 
service methodology and completed the project within Rockwell's tight timeline. 

WIN enables Rockwell Collins employees to perform the following functions through the Intranet: 

• Time Ent ry and Time Off - enter time sheets for government and non-government projects; register 
and track vacations, sick and personal days and leaves of absence. 

• Manage Personal Information - update addresses, phone numbers, dependent information, 
emergency contacts. 

• Organiza tional Directory - obtain organization structure and employee contact information, 
including employee photographs, through a searchable personnel director)'. 

• Training and Events - search for and enroll in training courses, and track training history. 

Primix was responsible for coordinating design and development between its twelve consultants 
delivering WIN, Rockwell's business managers, IT staff, D&T consultants implementing R/3 and SAP's 
core consultants. Primix developed an innovative architecture to meet Rockwell's flexible interface 
functionality and system performance requirements. The R/3 implementation process was highly 
iterative, involving a phased rollout approach and required tremendous project coordination skills to 
react to regression modifications in SAP. Primix was commended repeatedly for not only delivering 
WIN on time, but also for adding value to other project teams in their tasks to bring R/3 on-line. 
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Hughes Christiansen Corporation (HCC) 
MAPIT- Configuration and Quote Application 

HCC is a division of The Baker Hughes Corporation and is a worldwide leader in the design, 
manufacture, and application of Tricone® and diamond drill bits used in oil and gas drilling operations. 
To build a proposal, the company's worldwide field salespeople must often compare extensive 
performance information from wells drilled in similar geological formations across the world. This 
analysis is used to develop recommendations for the best drill bits and operating parameters to drill a 
customer's new well. The complex analysis process traditionally took sales and engineering two to three 
days to prepare. HCC realized that it could gain a strong competitive advantage by giving its world-wide 
sales force the ability to easily access pertinent information buried in the complex layers of technical 
specifications and drill bit performance histories across the corporation to prepare quotes in a matter of 
minutes - rather than days. Because the sales force operated in many of the most remote regions of the 
world, the Internet coupled with HCC's WAN was selected to deliver the automated analysis and bidtool 
- MAPIT. 

HCC selected Primix to deliver the solution based on our proven STEP I%I consulting methodology, 
expertise in complex systems integration, and ability to transfer knowledge to HCC's IT staff.. Primix 
delivered MAPIT in several phases over a seven-month period at a price of $1.8 million with a team of 
16 consultants. As initially anticipated, MAPIT now enables salespeople to draw on centralized product 
specifications and performance data collected from the company's worldwide drilling operations when 
recommending drilling technologies to customers. Additional features created during the Scope and 
Design processes include competitive performance data collected worldwide. This allows HCC 
salespeople to show customers comparative product performance data during the sales presentation. 

The "Empowerment" aspect of STEP'* was utilized to train HCC personnel so that they were able to 
provide most of the second phase of this evolving system. Phase II is currently in worldwide rollout. 
The new functionality built delivered in Phase II collects drill bit failure analysis from HCC's customer's 
so that the information can be utilized to improve product design and provide valuable feedback to their 
worldwide customer base. 

HCC was very pleased with MAPIT and Primix will continue to work closely with the client's internal 
team to deliver upcoming functionality improvements. 
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7.2 Graphical User Interface Design Expertise 

Functionality, robustness and performance offered via an Internet site are only a small part of the overall 
design requirements to deliver a truly successful solution. That is, an experience designed to meet both 
the technical AND emotional needs of the target end-user. Primix approaches every engagement with 
the objective of building a "persuasive IT solution". To achieve this goal, our sites must provide an 
intuitive and comfortable feel tailored to the specific characteristics of the targeted external and/or 
internal constituencies. Our creative design process is integrated tighdy with our STEP 1 M methodology 
to ensure that end-users receive the functionality they need at the performance levels they require - in an 
intuitve, user-friendly environment tailored to their unique perspectives. The two case studies below 
describe very different target audiences that were effectively won over by Primix's ability to design a 
persuasive solution tailored to their unique needs. 



Data General (DG) 

DGNow- On-line Sales and Order Management Application 

Data General, based in Westboro, Massachusetts, is a $1.5 billion supplier of storage and enterprise 
computing solutions for customers worldwide. The company's products include CLARiiON Fibre 
Channel storage systems, high-end NT and UNIX AViiON servers, and related software and services. 
DG realized that it could improve customer service, gain new customers and increase the efficiency of its 
sales force by creating a full-featured, highly personalized, on-line sales channel. 

Data General selected Primix over a wide array of competitors to deliver a highly customized solution 
which would complement the company's direct sales force by tightly integrating past puchasing trends 
with an on-line channel. Primix's creative process delivered a series of "Big Ideas" which have truly 
differentiated DGNow from other on-line sites. One feature, the NowList, allows a customer to bookmark 
frequendy bought items. Another feature, MwOrders lets the buyer save his or her favorite shopping list 
of products for quick reordering. The site provides users with a uniquely customized experience based on 
each registered user's feedback, historical purchases, current purchase orders and contract pricing, where 
applicable. The site features simplified product configuration, purchase tracking, cross-selling, context- 
driven menus, and real-time intelligence to maximize revenue by ensuring that customers can easily find and 
order the products they needs. 

IDC market analyst Janet Waxman reviewed the Data General Now site and proclaimed it to be one of 
the most integrated e-commerce implementations. "This site is well thought out and not only brings user 
friendliness features, but is supported with a comprehensive, integrated back-end to the company's 
existing systems," said Waxman. A summary story featuring DGNow was recendy included as the cover 
story of PC Week magazine. 
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Primix delivered this solution in a series of phases - on-time and on-budget - and continues to work closely 
with DG to contiuously enhance user functionality and data collection for DCs sales and marketing teams. 
Primix is also working closely with Data General - Europe to leverage DGNow by designing new features 
tailored to European customer's needs and providing multi-language functionality required to make users 
feel comfortable interacting with the site. 

ConAgra Refrigerated Foods (CRFC) 

Carrier Internet Response Update System (CIRUS) - Carrier Qualification & RFP Application 

CRFC, with $13 Billion in annual sales, is one the largest food products company in the world. CRFC 
ships these products using a large network of independent carriers. For 15 years the company had 
managed the process of examining carrier qualifications and creating proposals for service through a 
mainframe-based shipping management application known as SureShipping. The limitation of this 
system was that transactions surrounding the process had to be sent via EDI or FAX to carriers and all 
responses were manually entered into the mainframe. Essentially, every contact between producer and 
shipper required the intervention of a CRFC operator. CRFC chose to solve this limitation by 
implementing an extranet application. Primix was chosen to partner on the project with CRFC and 
Innovative Computing. 

Primix designed a user-friendly interface that simplified available transactions since many of the end- 
users were independent truck drivers with no PC experience. Specifically, Primix designed the interface 
to reduce the overall cost of the system compared to other approaches which CRFC had considered. 
The design hid the complexities of the back-end shipping application by tailoring the flow solely to 
information required by the user. At the same time Primix was able to add new functionality that was 
not available in the SureShipping application, such as data verification. The screen flow subtely educated 
the end-user making it easy for them to learn and interact with the system. Finally, CIRUS improved the 
performance of the SureShipping application by validating data at the front end, eliminating the need to 
correct errors later. CRFC was extremely satisfied with Primix Solution's performance as their 
communication problems were eliminated, operations cost savings were realized and the project was 
delivered on-time and on-budget. 



7.3 Architecture and Integration Expertise 

While many solutions delivered by Primix require high-performance and scalable application 
architectures, the two enterprise architectural case histories below illustrate engagements where Primix 
was selected to re-architect complex information system technologies that evolved haphazardly through 
corporate acquisitions over many years. Redesigning existing architectures to overcome infrastructural 
limitations developed over the life of an enterprise application is recognized as the most complex form 
of architectural design and development. 
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Lucent Technologies, Inc. (Lucent) 

ConfigPro - Distributed Product Configuration, Pricing, and Ordering Application 

Lucent maintains literally hundreds of distinct business critical applications that must exchange data in 
order to support current and future business processes. Historically, these systems were integrated via 
system-specific, custom-built application bridges. These proprietary bridges were expensive to build and 
maintain. Furthermore, when either end of a bridge changed, it was typically discarded, thereby wasting 
the potential benefits of reuse. 

Recognizing that new systems are routinely brought on-line while older systems are decommissioned, 
Lucent was looking for a robust architecture to support high-bandwidth data flows, enable significant 
reuse, and scale to meet the significant size of the company. 

In one particular application area, a critical product configuration system was having severe performance, 
stability, and scalability issues. Based on the Trilogy platform, this distributed product configuration 
application required connectivity to multiple backend systems in order to function effectively. These 
downstream systems included standard and custom, ERPs and databases. 

Primix Solutions was contracted to design and develop, a plug-and-play distributed architecture which 
could be used to both, immediately resolve the product configuration application issues, and also be 
capable of supporting the myriad of other systems with an extensible infrastructure. 

In the design phase of this engagement, we were able to specify a system that met all of Lucent's 
requirements. The solution was designed to leverage Lucent's existing investment in IBM MQSeries 
messaging technology and consisted of a COM-based distributed component architecture to hide the 
details of the underlying message system, while providing and easy-to-use framework for integrating new 
applications, servers, and services. Ultimately, this system utilized security, transactioning, auditing, 
naming, directory, and brokering services to provide the high performance, scalable and reliable plug- 
and-play environment that Lucent demands. The "plug-and-play" solution provided by Primix Solutions 
delivered performance and scalability far exceeding Lucent's expectations. Primix Solutions is currently 
developing the next version of the configuration application and is utilizing the same message-based 
distributed component architecture. A series of five additional re-architected solutions will be delivered 
over the next 15 months at Lucent. 

'Working with Primix, we developed a new strategy for our systems architecture that will increase our agility in developing 
business solutions while reducing the cost of development efforts. The Primix team did a phenomenal job designing this 
architectural strategy and delivering the solution on budget in only 90 days. " 

Stacy Gelman 

Chief Information Officer 

Lucent Global Service Provider 
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Level 3 

Real Time Billing and Order Management Solutions 

This Denver based Telecommunications Company has helped to redefine the industry with its innovative 
ideas and unique approach to bringing new services to its subscribers. These innovative approaches 
eventually forced the company to investigate a more robust and scalable architecture in-house for 
delivering timely information to its customers. 

Primix Solutions helped architect and implement a series of enterprise architecture solutions for this 
client using the tool set provided by Active Software. The core of the applications are being built and 
deployed around customer service. The first application was bill presentment and integrated the 
company's billing module with their own internal customer database. Presentation of the integrated 
solution is handled through a browser interface. Our responsibilities included designing and building the 
connectivity solution and designing the interface that presented this information to the customer. System 
highlights include real-time connectivity to the billing system and interactive queries defined by the 
customer. The connectivity solution supplied by Primix has been incorporated into Active's suite of 
adaptors. 

The second application focused on integrating the company's Order Management system into the 
lifecycle of an order at Level 3. The integration work consisted of four additional internal systems 
beyond Order Management. This integration automated the process of taking an order and decreased 
service time by over three weeks. 



7.4 DataBase Design Expertise 
AirTouch Cellular 

Designed, developed, and built ORACLE and INFORMIX databases and applications for the new 
systems development team and extensively tuned existing production databases. Installed and converted 
version 9 Oracle Applications to version 10. Developed, installed and configured a large (40 Gigabyte) 
ORACLE OLAP database used for segmenting the customer base. Implemented a very large 
INFORMIX database environment (200+ Gigabytes) on a pair of large SUN machines. Designed and 
implemented an industrial strength database backup and recovery system for AirTouch Cellular Los 
Angeles Market (130+ UNIX machines - SUN, HP, AIX, DYNIX) utilizing Legato Networker. Installed 
and configured Netscape Commerce Server and ORACLE'S WEB server product for a prototype 
intranet project. Performed database recovery of the production ORACLE Financial's database with no 
loss of data and minimum system downtime after database corruption. Upgraded existing ORACLE 
database's to the latest certified version. 
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ISO ALLIANCE (Limited Partnership of Perot Systems, Ernst and Young, and ABB) 

Installed, configured, and supported the development, testing, and production implementation of as 
many as 41 (at once) Oracle databases on 12 Digital UNIX machines. The project was to create both 
the operational and administrative systems for the ISO (Independent System Operator). The ISO is a 
completely new company created to run the deregulated Electricity market in California. Installed, 
configured, and supported all Oracle Applications databases (using version 10.7, 10SC including General 
Ledger, Accounts Payable, Purchasing, Fixed Assets, Project Accounting, Electronic Data Interchange 
(EDI), and Accounts Receivables). Worked extensively with developers to debug and tune the 
applications and customizations of Oracle Financials and Oracle Applications. Implemented the super 
high availability operational systems using Oracle Parallel Server operating on a Digital UNIX 
TruCluster machine. 
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8.0 Business Proposal 

This section describes our Fixed-Time/Fixed-Price proposal to deliver Bid Manager's Design Phase. As 
described in the Project Plan, Primix's traditional creative process and functional Scope STEP ni were 
modified to meet CONVEX's needs during the Requirements Weeks. Therefore, Bid Manager's Design 
phase will begin with a four-day Scope following the STEP IM methodology to formally build a detailed 
Functionality Matrix for Phases I, II & III - but focused especially on Phase I. From this matrix, we will 
joindy determine the specific functionality required to deliver maximum business value to the target end- 
users within the time guidelines required to deploy Bid Manager. Immediately following Scope 
completion, we will launch the formal Functional and Technical Design Phase targeted for completion 
twenty-one (21) business days later. 

Normally, we would not be able to provide a Fixed-Time/Fixed Price bid for Design until the 
Functionality Matrix was completed. However, we believe that logical-E and Primix learned enough 
about the overall CONVEX solution and the business requirements for Bid Manager, that we are 
comfortable providing hard pricing and duration for this phase. At the completion of Bid Manager's 
Design Phase, we will be prepared to deliver a Fixed-Time/Fixed-Cost bid for the Development Phase. 



8.1 Fixed Price and Fixed Time Design Proposal 

This Phase will be comprised of the functionality matrix design/approval process and Bid Manager's 
functional design and the technical design. The purpose of this phase is to finalize the detail of the 
required screen layout and supporting functionality. Primix and logical-E determined that the effort 
required to complete this process will require five (5) weeks, seven (7) consulting skill-sets to cover the 
required range of technical disciplines, a Client Partner and additional intermittent personnel support as 
required to deliver specific core expertise. Deliverables provided at the end of this phase will include the 
Design Document, consisting of the functional and technical specifications, the screen mock-ups, and a 
detailed development plan. As mentioned above, a delivery from Design will be a Fixed-Time/Fixed- 
Cost bid for Bid Manager's Development Phases. Per CONVEX's direction, Primix and logical-E 
anticipate beginning the Design Phase on Monday, July 19 th . Primix and logical-E will deliver the 
complete Design Phase for a fixed price of $291,000. 

♦It is assumed that CONVEX will pay reasonable travel and living expenses at cost. Travel and living 
expenses are not included in the Design fixed price above. 
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8.2 Participant Discipline Requirements for Scope/Design STEP 

Primix Solutions and logical-E have determined the mix of skill categories required to deliver the Bid 
Manager Design. They are as follows: 

• Project Manager - Manages project schedule, resource assignments, reporting, and deliverable 
production 

• Project Client Partner - Manages inter-company relationship, contract administration and approves 
deliverables 

• Senior System Architect — Lead application designer who provides senior project technical leadership 

• Data Base Lead - Designs and develops database schema and database loading and reporting 

• Creative Lead — Designs application look & feel, usability, web site templates, and brand 
development 

• HTML Consultant - Primary developer of web applications including HTML and database access 
methods 

• Business Analyst/ Associate Consultant — Provides software development and documentation 
support 

• Industry Analyst - Provides domain knowledge and industry best practices expertise that contributes 
to design. This role will be filled by Convex. 



Proposed Design Team 



Sr. Project Manager 


$l,600/day 


for 25 days 


$40,000 


Sr. Systems Architect 


$l,600/day 


for 25 days 


$40,000 


Data Base Lead 


$l,600/day 


for 25 days 


$40,000 


Creative Lead 


$l,300/day 


for 25 days 


$32,500 


HTML Consultant 


$l,000/day 


for 25 days 


$25,000 


Business Analyst 


$l,200/day 


for 25 days 


$30,000 


Associate Consultant 


$l,100/day 


for 25 days 


$27,500 


Client Partner 


$2,000/day 


for 12.5 days 


S25.000 






TOTAL 


$260,000 




Plus 12% contingency fee for Fixing cost 


$31,200 






Fixed Bid 


$291,000 
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8.3 Best-Estimate Price for Development 

The Development Phase is comprised of the implementation and integration stages. The purpose of this 
phase is to take the detailed technical and functional designs that evolved from the Design Phase to build 
unit tested coded components. These units will then be integrated and tested before being deployed. 
Our current best-estimate range for Bid Manager's Development Phase is $800,000 to $1,200,000. Once 
again, a Fixed-Time/Fixed-Cost proposal for the Development Phase will be delivered upon completion 
of the Design Phase. 
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1 Purpose of this Document 

This document describes system functionality and design of the Buzzsaw Bid Management System, 
formerly known and referred to herein as CONVEX. The document is written from a business 
process perspective. The requirements described in this document have been deduced from 
numerous meetings and documents, and represent Phase One system design. 



2 Introduction and Overview 
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Figure 1: Construction Business Organizational Overview 

The CONVEX system will bring the construction business into a complete, automated online 
system that integrates project management, bid management, and supply chain functions in a 
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centralized Internet system. Ultimately, the CONVEX system will be the catalyst for a new business 
model that changes or eliminates common roles in existing business models (paradigm shift), saving 
the industry billions in overhead by facilitating resource reduction, time, and efficient resource 
management. The CONVEX system will also leverage new business relationships made possible by 
uniting all the industry's business entities into a single system. The CONVEX system will become an 
ideal portal site by combining construction business relationships, captured business data, industry 
data, and news. 

The CONVEX system will be designed to permit valuable and simple access to project authoring 
(invitation to bid) and bid submission processes. The system will also provide significant value in the 
form of services and information retrieval for portal users. A key element will be the application of 
real world business knowledge in the processes. Therefore, the CONVEX system will not 

• Make assumptions about which user can author projects or become a bid recipient 

• Attempt to enforce a specific workflow or make assumptions about what actors participate in a 
particular workflow, which is particularly important in m a naging subcontractors or other 
contractors. 

Example: General contractors (GC) need flexibility when selecting recipients of certain 
documents since contractors are in competition with other contractors. GCs want their 
favorite subcontractors to win the bid, and will do whatever it takes to ensure that they have a 
fighting chance. A GC may not be helpful to a subcontractor he suspects is bidding for a 
competing GC. 

The CONVEX system must consider the workflow participants when implementing GC and 
subcontractor user interfaces. The CONVEX system must give users the ability to work the way 
they are accustomed to working and not jeopardize their businesses' existing processes. 

This document will address the first of four phases of development of the CONVEX system: 

• Bid Management 

• Document Distribution (Blueprints) 

• Supply Chain automation 

• On-line Auction 

While consideration of other phases is important in system design, the purpose of this document is 
to define the functionality of a Phase One deliverable with consideration of future phases. These 
features will run in the context of a portal website providing valuable content and services for the 
construction industry. Specification of the portal site is outside the scope of this deliverable as well. 

2.1 System Actors 

This section provides an overview of the primary actors in the CONVEX system. The significant 
reoccurring process pattern occurring between the actors in the CONVEX system will be: 

• Soliciting of bids 

• Submission of bids 

• Selection of low bid 
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The pattern occurs from the architect and engineers down to the building product manufacturers. 
The system design should take advantage of this pattern architecturally since it will yield a simpler, 
more robust system design. The Project will be the primary system object that is the center of all 
process activities. 

2.1.1 Owner 

Project owners can be developers (often a corporate entity) or individuals. The owner purchases 
land and employs the services of an architect and other consultants. An RFP may be created and 
distributed to one or more architects, engineers, and construction managers. The owner typically 
delegates the authority of day-to-day project management 

2.1.2 Construction Manager 

A construction manager acts as a proxy for the owner. Some construction managers take an active 
role in project management and others do not The CONVEX system will treat construction 
managers as a proxy for the owner. 

2.13 Architect and Engineers (A/E) 

On behalf of owners, architects and engineers design an agreed concept on existing property 
acquired by owners. The A/Es prepare all the plans and documents that define the project The 
architect submits an RFP or instructions to bid (contained in a bid package) to engineers and general 
contractors. The architect generally takes responsibility for keeping a project within budget. 

2.1.4 General Contractors (GCs) 

GCs are the organizational force in construction projects. They are responsible for coordination of 
the trades and understanding plan details to ensure an accurate bid and work scope. GCs play a 
middleman role between the owner, architects, engineers, and subcontractors. All communication in 
a project flows through the GC. A GC typically responds to an RFP from an owner, construction 
manager, architect, or engineer. The GC will determine the required trades (CSI codes) from the 
plans and create a bid list (contractors) organized by trade. The GC will then send an "Invitation to 
Bid" to contractors on the bid list. CONVEX will provide the most value to GCs by facilitating and 
managing the volumes of communication that must occur between a GC and their (average 300- 
500) subcontractors. Use of CONVEX by GCs will help drive subs to the site. 

2.1.5 Subcontractors 

Subcontractors represent the critical mass in the CONVEX system because they are the single 
largest group of users and will be the major source of revenue for CONVEX (Phase One). The 
subcontractor is responsible for processing bid submissions typically from GCs. Subcontractors 
offer services for specific trades (CSI codes). The subcontractor often submits his own "Invitation 
to Bid" to other subcontractors, suppliers, and building product manufacturers. The CONVEX 
system must provide a simple and valuable user experience for subcontractors. 
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2.L6 Suppliers 

Suppliers and distributors provide products from several building product manufacturers. In many 
cases they provide services to contractors by finding and selecting products. Although, the building 
product manufacturers work with suppliers and distributors, many would prefer to have a direct 
relationship with contractors (increasing their margin while having a tighter control on their 
customer base). 

2.1.7 Building Product Manufacturers (BPM) 

BPMs create and sell products for one or more construction trades. The BPM is the bottom of the 
food chain in the construction business pyramid. The primary activity of a BPM is soliciting owners, 
architects, and engineers to encourage specification of their product The secondary activity is 
actually responding to an "Invitation to Bid" from GCs and SCs. 

2.1.8 Building Service Providers 

Building service providers provide various services for contractors. These system actors will have an 
increasingly important role in future phases of development. 

2. 1.8. 1 Document Reproducers (Blue printers) 

Each project will have an association with one or more document reproducers. In Phase One 
document reproducers will be presented to contractors for informational purposes (such as, whom 
to pick up plans from). In later phases CONVEX will electronically distribute documents and ship 
documents to contractors. 

2. 1.8.2 Building Information Providers 

Building information providers are sources of media related to trades, contractor lists, industry 
metrics, industry news, standards, and new projects. In Phase One, the primary role building 
information providers play is managing trade codes (CSI), industry news, product information, and 
project news (CMD). 

2.2 Primary System Roles 

System roles represent the key contexts a user will play within the CONVEX system. Detailing the 
roles is an important aspect of the CONVEX system since the business vision of the CONVEX 
system is to empower and change the business model of the construction business. The CONVEX 
system should not couple the primary system roles to any particular type of user or contractor. Any 
user should be able to author a project in the CONVEX system. Also, any contractor (a business 
selling a product or service) should be allowed to be a bid recipient for their services or product 
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2.2.1 Project Author 

A project author will manage a project from all aspects. In Phase One this actor will be primarily 
authoring projects for bidding. This will include selecting trades and picking contractors for a bid 
list The project author sends the Invitation to Bid, Scope Memo, and Addenda documents. 

2.2.2 Bid Recipient (Contractor) 

A bid recipient will be any contractor who is invited to bid for products or services. This will be 
anyone placed on a project's bid list by a project author. The bid recipient sends Request for 
Information (RFI) or Bid documents. 

2.2.3 Bid System Administrator 

A bid system administrator has the capability to modify the CONVEX account This capability 
includes, but is not limited to: 

• Changing company information 

• Adding/ changing users 

• Importing bid fax data 

• Managing CSI codes and lists 

• Managing contractor lists 

22.4 Portal User 

A portal user is any user visiting the CONVEX site for information purposes and is not a registered 
user. The portal user is not a system role for the bid system. 

2.3 Primary System Objects 

2.3.1 Project 

A project is the primary unit of work in the CONVEX system. It is the focal point of all the activity 
in the CONVEX system. A project brings together all the associations of bid management 

23.2 Bid Documents/Package 

The bid documents are the initial distribution of documents from the A/Es to the GCs. They 
normally include plans, specifications, and instruction to bidders. The reception of this package 
starts the bidding process from the general contractor down the food chain. 
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233 Bid List 

The "Bid List" represents the list of contractors who are bidding on a particular project The "Bid 
List" is often referred to as the "sub list" associated with the project. This is a reference to the 
"subcontractors" bidding on a project. 

23.4 Invitation to Bid Document 

This document starts the bidding process by soliciting bids from contractors. The goal of submitting 
this document is a "Bid" representing the lowest possible cost 

23.5 Bid 

The "Bid" is the contractual document ultimately produced in response to an "Invitation to Bid" 
document It represents a contractor's agreed cost for services or products. 

23.6 Request for Information (RFI) Document 

Contractors requesting explanation or clarification of building design from A/Es create the RFI 
document An addendum is often the response to a RFI. 

23.7 Addendum Document 

Whenever plans or specifications are revised or clarified, A/Es will create an addendum document 
detailing the change. The GC ensures that this document is sent to all trades that are impacted by 
the change. 

23.8 Scope Memo Document 

A scope memo document provides information to contractors to help properly bid a project The 
documents may point out certain plans or design details that a contractor might overlook The 
documents can play a strategic role in the bidding process 

Example: A contractor may choose not to send a scope memo to a contractor he suspects is 
bidding with a competing contractor. 
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3 The Bid Management System 

3.1 Portal Home Page 

The portal home page is www.buzzsaw.com . This is the primary marketing vehicle and destination 
of non-registered users (portal users). The system must provide a dynamic page that offers all users 
some value that will encourage revisits and minimize drop-offs. The layout and feature set should be 
story boarded and scrutinized by domain experts who understand the target users. This should also 
be coupled with usability trials with real users. 

The details of the portal site are beyond the scope of this specification, but it is expected that it will 
include links for the following: 

• Member login 

• New user registration 

• Company detail (e.g. Who we are, contact information, jobs) 

• Marketing (e.g. press releases, product/ services description, Customer list, FAQ, industry 
partnerships) 

• Search 

• Industry resources (e.g. product database, contractor database, trade news, trade 
publications, related sites) 

• Customer support (e.g. site tutorial, common issues, support FAQ, knowledgebase, support 
e-mail and telephone numbers) 

3.2 Member Login 

The member login screen will be the port of entry for daily/ frequent users. This will be the page 
book-marked or placed on the users' desktops. After login, the CONVEX system will navigate users 
to the proper view of the system based on the user capabilities and/ or role-played in the CONVEX 
system. Users are assigned a unique CONVEX membership ID. The ID will become an industry 
accepted ID and will be tied to benefits at other sites and businesses. 

3.2.1 Enter Login Information 

The CONVEX system will prompt users for a login name and password. Ideally, the CONVEX 
system should attempt to automatically determine the user by checking for Web browser cookies, or 
resolving user identity (by URL) presented to the CONVEX system. The bid management system 
will check for the existence of such a cookie and force a prompt for the user name and password if 
it does not exist The password will not be echoed to the display. 
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3.3 Account Administration (User Registration) 

Every CONVEX user will be associated with an account. The CONVEX account can be created for 
a sole proprietor or a corporation with several CONVEX users. 

3.3.1 General Account Information 

The most data-entry intensive operation in the CONVEX system is the creation of the CONVEX 
account. The information outlined below must be captured simply with the least possible user-labor. 
Fields that are optional need to be marked and the process should allow a user to revisit filling in 
detailed data or updating data in the future. 

3.3.1.1 Membership ID 

The CONVEX system will assign users unique membership IDs that will be used on the CONVEX 
system accepted at partner sites. The ID will become industry accepted and entitle users to special 
services or discounts with partner sites and companies. 

3.3. 1.2 Company Information 

The company detail can vary slight based on company type, but ideally from a systems' viewpoint 
companies are treated uniformly. The system roles will drive the actual business processes in the 
system. The CONVEX system can use company type to make some obvious assumptions, but the 
CONVEX system will allow users (via profiles) to change their default view of the CONVEX 
system. 

3.3.1.2.1 Name 

This is the legal name of the company that will be used in all the public and private lists. 

3.3. 1 .2.2 Company Type 

A customer will be asked to categorize their business. While the system does not restrict what a 
company can do when selecting a particular company type, it is important that a company propedy 
categorizes itself. The CONVEX system databases will be organized and presented using company 
type, so an erroneous classification could have significant impact to a company's visibility in the 
CONVEX system. 

• Owner 

• Construction Manager 

• Architect 

• Engineer 

• General Contractor 

• Sub-Contractor 

• Supplier/Distributor 

• Manufacturer 
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3.3. 1 .2.3 Work Type (TBD- 20 to 30) 

Work type will describe the type of projects that are the core competency of this contractor. 



3.3.1.2.4 MWDVS 



These classifications are important for qualification of contractors for certain projects: 



• Minority 

• Women 

• Disadvantaged 

• Veteran 

• Small Business 

3.3. 1 .2.5 Bidding Range 

This field determines the range scope of project tackled by the contractor. 



3.3 


1.2.6 Address 


3.3 


1.2.7 Phone 


3.3 


1.2.8 Fax 


3.3 


1.2.9 E-Mail 


3.3 


1.2.10 URL (Web Site) 


3.3 


1.2.11 Contact 


• 


Login Name 




Name 


• 


Tide 


• 


Address 


• 


Phone 


• 


Fax 


• 


E-mail 



3.3.2 User Setup 

Many users can be associated with a single CONVEX account. This will allow different user activity 
to be audited on a per project basis. The CONVEX system will also allow general capabilities to be 
assigned per user. The user who created the CONVEX account will become the default 
administrator of the CONVEX account. 



Convex Technologies Functional and System Design Specification 
Phase One 



eBuilt 



Page 9 



PRLNT OF DRAWlftGS 

AS ORIGINA LLY FILE D | * 



3.3.2.1 Add User 

The CONVEX system will allow one or mote users associated with a company account. 

• Define User Capabilities 

Users can be assigned different capabilities that grant access to different functionality associated 
with the CONVEX account. 

• Administrator 

Administrators can update CONVEX account information including adding, updating, and 
deleting users. 

• Allowed to Author Projects 

This capability allows users to create projects in the CONVEX system. 

• Allowed to Bid (Bidding) 

This capability allows users to create bids (respond to invitation to bid). 

• Login Name 

• Name 
•' Tide 

• Address 

• Phone 

• Fax 

• E-mail 

• URL 

3.3.2.2 Update User 

This function allows a CONVEX administrator to change a user's detail information. 

3.3.2.3 Delete User 

This function allows a CONVEX administrator to delete a user's login from the CONVEX system. 
33.3 UCI/CSI Code Management (Trades) 

Every contractor has traditionally maintained a version of CSI codes (trade codes) that are coupled 
to their internal business processes (such as, cost center). The CONVEX system will be a vehicle to 
encourage the adoption of uniform UCI/CSI codes. 

3.3.3.1 Add CSI Codes 

This function will allow a user to add custom CSI codes or select a CSI code from the CONVEX 
UCI/CSI list. 
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3.3.3.2 Edit CSI Codes 

This function will allow a user to edit an existing CSI code description or number. 

3.3.3.3 Delete CSI Codes 

This function will allow a user to delete a CSI code from the private data. 

3.3.3.4 Search CSI Codes 

This function will allow a user to search for CSI codes by name or number from private and public 
data. 

3.3.3.5 Display Zero Count CSI 

This function will display all the CSI codes in private data that have no associated contractors. 

3.3.3.6 Update Private to Public CSI map 

This function will allow a user to update the map, which translates the private CSI code to the 
CONVEX UCI/CSI public data. 

3.3.4 Contractor Maintenance 

Mamtaining contractors' lists is critical to GCs and other entities (which manage the bid process). 
Since the process is heavily dependent on communication to contractors, it is vital that the 
CONVEX system simplify the management of contractor resources. 

3.3.4. 1 Find Contractors 

Finding contractors in the CONVEX system will be valued activity. Today GCs spend a significant 
amount of time searching for qualified contractors. The CONVEX system will improve the 
situation by giving contractors access to a public database of industry rated contractors. 

3.3.4.1.1 Find Contractor in Public Data 

This function will allow a CONVEX user to find a contractor based on all unique contractor 
attributes, and includes, but is not limited to: 

• Name 

• Location 

• Trade 

• Labor type 

• Credit rating (D&B) 

• Industry rating 
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3.3.4. 1 .2 Find Contractor in Private Data 

This function will allow a CONVEX user to find a contractor based on all unique contractor 
attributes, and includes, but is not limited to: 

• Name 

• Location 

• Trade 

• Labor type 

• Credit rating 

• Industry rating 

3.3.4.2 Add Contractor to Private Data (master list) 

This function will allow a CONVEX system user to add a contractor to their private data. 

3.3.4.3 Remove Contractor from Private Data 

This function will allow a CONVEX system user to remove a contractor from their private data. 

3.3.4.4 Contractor Lists 

The CONVEX system will allow users to maintain multiple, privately named lists of contractors. 
These lists can share the same contractors, so the lists will be treated as references to the master 
private database of contractors. 

Example: If a contractor's phone number changes, that change is reflected in all lists that 
contractor appears in. 

Contractor lists provide a simple tool to organize contractors. A list of contractors could exist for a 
particular region (such as, Riverside County Contractors) or project type (such as, Tilt-up 
Contractors). 

3.3.4.4.1 Create Contractor List 

This function allows users to create a new (named) list of contractors. After creation, this list can be 
used to create a unique named set of contractors. 

3.3.4.4.2 Add Contractor List 

This function allows users to add a contractor to a specific list. The contractor can be derived from 
the user's private data (master list) or the CONVEX public database. 

3.3.4.4.3 Update Contractor List 

This function allows a user to change contractors associated with a particular private contractor list. 
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3.3.4.4.4 Delete Contractor List 

This function allows a user to delete a contractor list from a user's private data. 

3.3.4.4.5 Find Contractor 

This function allows a user to find a specific contractor in a contractor list. 

3.3.4.4.6 Associate CSI Codes 

This function allows a user to associate one or more CSI codes to a contractor. This activity is 
important in ensuring that a contractor is presented as an applicable resource during the bid 
authoring process. 

3.3.5 Bid Fax Importation 

The CONVEX system will allow users to upload BidFax .CSV files. The primary imported data 
elements are: 

• CSI Codes 

• Contractors 

• Project Templates 

3.3.5.1 Import CSI codes 

The BidFax imported CSI codes become a user's private CSI codes. Users will be required to map 
the private CSI codes to the CONVEX CSI codes. The system will also offer users the option of 
converting their CSI codes to the CONVEX CSI codes. 

3.3.5.2 Import Contractors 

The BidFax imported contractors will be loaded into a user's master private database. 

3.3.5.3 Import Templates 

The BidFax imported project templates will be loaded into a user's master private database. 
33.6 Membership/Paid Services 

The primary vehicle to generate revenue in Phase One is contractor membership upgrades. Properly 
marketed, the value of upgrading to Gold Membership should be viewed as irresistible from the 
contractor perspective. 
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3.3.6. 1 Select/ Upgrade Membership Level 

Upgrading membership should be a visible option to users who have not upgraded their 
membership. This probably means that every screen might have a click to upgrade icon for non- 
upgraded users. 

3.3.6.1.1 Bronze 

This is a free feature that provides a basic contractor listing service. The listing will appear after 
Silver and Gold listings. 

3.3.6.1.2 Silver 

This is pay level one and provides some value in positioning over Bronze level contractors. The 
contractor listing will appear after Gold listings. 

3.3.6.1.3 Gold 

This is pay level two and provides value in positioning over Bronze and Silver level contractors. The 
contractor listing will appear in the top group of contractor Gold listings. 

3.3. 6.2 Buy Extra Faxing Units 

A user is allocated "N" free faxes per month. If a user exceeds "N" faxes, they can buy 1000 faxes (a 
fax unit) for $150.00. 

3.3.6.3 Secure Purchase Transaction 

A user will be prompted on a secure page (made very obvious) for credit card information. The 
CONVEX system will prompt for the minimum fields required for a credit transaction with a 
merchant bank. A simple, secure form will be used that describes what is being purchased. Upon 
transaction completion a landing page will be presented with an order number. The landing page will 
be printable. 

3.3.7 Account Preferences 

User customization of system defaults. While some preferences are obvious today, due to the nature 
of system user interface design and development, it is believed that the definition of preferences may 
be driven by design of user interface and the system itself. 

3.3. 7. 1 Publish Bid Awards 

By default publish all bid awards. 
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3.3. 7.2 Publish Contractor Lists 
By default publish bid lists. 

3.3. 7.3 Publish Document Reproducers 

By default publish a project's blue printers. 

3.4 Project Authoring 

Project Authoring is the system activity that starts the bidding business process. The interesting 
aspect of the business process is the recursive nature of the process. The root process occurs when 
the owner/developer submits an RFP to A/Es. The A/Es submit an RFP and/or bid documents to 
GCs who, in turn, submit an invitation to bid to subcontractors, suppliers/wholesalers, and BPMs. 
The cycle repeats at every level. 

3.4.1 Create Project from another Project or Project Document 

When a contractor receives an invitation to bid from another contractor an automatic association is 
made to a project. A contractor can pull the list of associated projects or documents and create a 
new project. 

3.4.2 Create Project from Template 

The CONVEX system will provide a function that will allow the initial state of a project to be 
derived from a previously saved project template. Every project can be saved as a template. Project 
templates are a tool to reuse common data attributes between projects. A contractor may want to 
reuse the CSI codes (trades) or the contractors of previous project 

3.43 Project Definition 

Capture the detail, which will uniquely identify and describe a project. 
3.4.3.1 Details 

The items in the following items define a project. The bulk of the information captured should not 
be mandatory. The minimum information required to define a project should be small and obvious 
to the project author. Keeping the use-cost of the CONVEX system to a minimum will be a key 
factor in user retention. The CONVEX system use experience needs to be perceived as worthwhile. 
Excessive data entry could easily become a barrier towards mass adoption of the CONVEX system. 

• Tide 

The tide is the primary legal description of the project. 

• Location 

• Bid Date and Time 
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• Owner Information 

• Architect Information 

• Consultant Information 

• Bidding Information 

• Type of Project 

• Proj ect Estimated Valuation 

• Scope of work description 

• Document Reproducer 

3.4.4 Bid Type 

Bid type will be used for categorization, driving some business logic differently depending on the 
project context 

3.4.4. 1 Public Works (City/ State /Federal Government) 

Public works projects are open to everyone that qualifies to bid the project. These projects often 
mandate equal opportunity employment. Canada does not have equal opportunity employment 
issues. These projects may require tracking of MWDVS attributes. 

3.4.4.2 Private Competitive Bid 

In the case where more than one general contractor is bidding on a project with private ownership it 
is a private competitive bid type. Union labor may be required due to loan requirements from union 
based institutions. Prevailing wages may be required if a portion of the funds come from a 
government-funded program. 

3.4.4.3 Negotiated Bid 

Negotiated bid is becoming the popular choice in the commercial construction business. The owner 
will entrust the project with a single general contractor. The GC will manage the bidding process by 
soliciting bids from subcontractors and suppliers. Union labor may be required if a union lending 
institution is involved. Prevailing wages may be required if a portion of the funds come from a 
government-funded program. 

3.4.5 Labor Type 

Labor type defines employee guidelines for pay and other legal considerations. 
3.4.5.1 Prevailing Wage 

Wages are determined to meet government prevailing wage guidelines. 
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3.4.5.2 Union Wage 

Wages are determined to meet union guidelines. 

3.4.5.3 Open Shop 

Wages can be determined per contractor and are not constrained by union or prevailing wages. 

3.4.5.4 Unknown 

When the labor type cannot be determined, the CONVEX system will categorize. 

3.4.6 Select Trades 

The project plans include a list of trades, which help define the list of required trades. Experienced 
contractors review projects plans to further refine the list of trades to help ensure a successful bid. 

3.4.6. 1 Trade selection (private CSI codes) 

The CONVEX system will have a simple tree model for selection of CSI codes and association to a 
project. 

3.4.7 Select Contractors 

Select contractors based on selected trades from specific contractor list. The system will prompt 
contractors in private data space and public data space. Normally a single contractor list is selected 
per project. The CONVEX system will transparendy map the CONVEX user's private CSI codes to 
the CONVEX system CSI codes. 

3.4. 7. 1 Contractor selection using Private Data 

The CONVEX system will prompt for CSI codes from the user's private data. 

3.4. 7.2 Contractor selection using Public Data 

The CONVEX system will prompt for CSI codes from the CONVEX public data. Contractors will 
be selected by their trade and profile. The system will also optionally add the contractor to a private 
contractor list. 

3.4. 7.3 Select Bid Recipients 

This function allows a contractor to be selective of whom in the associated project will get a 
particular document. 
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3.4.8 Project Preferences 

Project preferences, which allow overriding of account defaults. 

3.4.8.1 Publish Bid List 

Publish this projects bid list to the public database. 

3.4.8.2 Publish Bid Award 

Publish this projects bid award to the public database. 

3.4.8.3 Publish Document Reproducers 

Publish project's blue printers to the public database. 

3.4.9 Save Project as Template 

The CONVEX system will provide a function to save a snapshot of a project as a template. This will 
allow future re-use of project settings, CSI codes, and contractors. 

3.5 Document Management 

Document management is the focal point of communication in the CONVEX system. All parties in 
the CONVEX system will formally communicate via document exchange. Timely routing and 
delivery of important documents will be a critical requirement. 

3.5.1 Create Document 

This function allows a contractor to create documents for delivery to other CONVEX users. The 
correspondence can be project-centric or general correspondence outside a project context 

3.5. 1. 1 Create New Document 

Allows a contractor to create documents supporting the project-authoring role. 

3.5.1.1.1 Invitation To bid 

This document is created relative to a project and once for a project The CONVEX system will 
track which contractors of the project have been sent this document. 

3.5.1.1.2 Addendum 

This document is created as needed during the project bidding process. The recipients may vary 
based on trades. The CONVEX system will track who has received this document 
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3.5.1.1.3 Scope Memo 

A scope memo is created when more information is needed to clarify the project plan/specifications 
for a particular trade. This helps the contractors prepare a better bid 

3.5.1.1.4 Memo 

A memo is any general correspondence that is not formally modeled. 
3.5. 1.2 Re-Send Previous Document 

As contractors are removed and added to a project, the CONVEX system must allow previous 
documents to be re-sent to new contractors. The system will track and allow re-selection of 
previously sent documents. 

3.5.2 Select Recipients 

Selecting the recipients will be similar to selecting e-mail contacts. 
3.53 Send Document 

The CONVEX system will allow contractors to send documents using a single click operation (the 
default method is a facsimile). Another method may be chosen. The method applies to all selected 
recipients. 

3.5.3.1 Fax 

Send a document via CONVEX system FAX services. 

3.5.3.2 Print for Faxing 

Print a document in the browser using a format that is faxable. 

3.5.3.3 CONVEX E-mail 

Send a document using the internal CONVEX document delivery service. 

3.5.3.4 Internet E-Mail 

Send a document via SMTP service with some acknowledgement of receipt. 
3.5.4 Fax Capture Documents 

The CONVEX system will allow a user to send faxes to the CONVEX system to be associated to a 
project, or to appear in a Project In Box. (This functionality may be added after phase 1). 
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3.5.4. 1 Print Bar Code for FAX capture 

The CONVEX system will allow a user to print a bar code page that will help identify the incoming 
fax document. 

3.5.4.2 Add Captured Documents To Project 

Faxes that are captured will be routed to the CONVEX system and added to the associated project. 

3.5.4.3 Associate Pages to Trades 

The CONVEX system will allow a user to associate individual pages to trades. 

3.6 Bid Management 

Bidding is the process where a contractor responds to an invitation to bid. 

3.6.1 Search for Projects 

Search for new bidding opportunities. The CONVEX system will provide simple and flexible ways 
to search for new projects to bid. This functionality is a key value to subcontractors and suppliers. 

3.6.1.1 Search for new projects 

Based on the CONVEX contractor profile, the CONVEX system will find new bidding 
opportunities. The system will allow a contractor to send a memo soliciting a bid opportunity. 

3.6.1.2 Search for projects near my area 

The CONVEX system will allow a contractor to search for bidding opportunities outside of his 
defined work area. 

3.6.2 View Projects 

The contractor will view correspondence categorized at two levels: By document type and by 
project. 

3.6.2.1 Inbox 

The inbox is organized by project. Urgent documents like "Addendum" causes a display alert to 
appear which a user can click on. 
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3.6.2.1.1 Addendum (alterable) 

This document is important to the contractor because it represents a modification to specifications 
or plans, which are critical to the bidding of the project. These documents must be available to a 
contractor in a timely manner. The CONVEX system will actively alert a contractor when a new 
addendum arrives. 

3.6.2. 1 .2 Invitation to Bids 

Receiving the invitation to bid is the beginning of the bid process for a contractor. This document 
represents potential business and the CONVEX system needs to empower contractors to solicit 
invitations to bid every project applicable to the contractor. 

3.6.2.1.3 Scope Memo 

A scope memo is normal information provided by the GC to help the contractor in his bidding 
process. 



3.6.2.1.5 CONVEX Mail 
General CONVEX system e-mail. 

3.63 Response to Document 

Responding to received documents will be simple using the CONVEX system. Users will be 
presented with documents in an organized inbox with a status, which shows read and responded. 

3.6.3. 1 Select Document Type 

The CONVEX system will exploit the common e-mail user interface pattern when handling a 
project's formal correspondence. Documents will be organized by type in the main inbox folder. A 
count of new documents will appear next to the folder name. Documents will be organized in 
folders by project This interface will be a unique feature of the CONVEX system and will evolve as 
more is learned from prototyping and usability reviews. 

3.6.3.1.1 Bid/Decline 

This document will normally be created in response to an invitation to bid. 

3.6.3.1.2 RFI 

This document will normally be created in response to an invitation to bid, scope memo, and 
addendum. 



3.6.2.1.4 CONVEX Project Mail 

General correspondence associated with a project. 
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3.6.3.2 Send Response 

Documents are automatically routed to the project author. Guaranteed receipt is not possible with 
all document delivery methods. 

3.6.3.2.1 Fax 

CONVEX system sends the document as a FAX. 

3.6.3.2.2 Print for Faxing 

CONVEX system prepares output for printing that will be faxed. 

3.6.3.2.3 CONVEX E-Mail 

The CONVEX system delivers mail directly to a CONVEX users inbox. 

3.6.3.2.4 Internet E-Mail 

The CONVEX system uses Internet e-mail SMTP to deliver documents. 
3.6.4 Create Document 

This function allows a contractor to create documents for delivery to other CONVEX users. The 
correspondence can be project-centric or general correspondence outside a project context. 

3.6.4.1 Select Document Type 

The contractor should have one-click access to any common function. The ability to create 
documents should be designed to facilitate ad hoc workflow. 

3.6.4.1.1 RFI 

A contractor can author an RFI when there is an issue, or if clarification of plans/ specifications is 
required. 

3.6.4.1.2 Memo 

A memo is any general correspondence not formally modeled. This can be used for bidding inquiry, 
sales solicitation, and so on. 

3.6.4.2 Select Recipients 

Selecting the recipients will be similar to selecting e-mail contacts. The CONVEX system should 
also allow a contractor to select a project as a destination, which would imply the project's project 



manager. 
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3.6 A.3 Send Document 

The CONVEX system will allow contractors to send documents using a single click operation. The 
default method is a facsimile, although another method can be chosen. The method applies to all 
selected recipients. 

3.6.4.3.1 Fax 

Send a document via CONVEX system FAX services. 

3.6.4.3.2 Print for Faxing 

Print a document in the browser using a format that is faxable. 

3.6.4.3.3 CONVEX E-mail 

Send a document using the internal CONVEX document delivery service. 

3.6.4.3.4 Internet E-Mail 

Send a document via SMTP service with some acknowledgement of receipt 

3.7 Calendar 

The Calendar is a Web-based calendar that offers PIM-like functionality to registered users. This 
could be a co-branded site offering Web-based PIM service. Some opportunity exists to customize 
functionality to tightly integrate into the CONVEX system/projects associated with the user. 

Example: Bid submission dates could appear on the calendar and in to do lists. Similar to 
http:/ /www.hotofficexom (This functionality may be added after phase 1). 

3.8 Reporting 

Produce reports about contractors (and suppliers/BPM), project metrics/statistics, user metrics, and 
fax activity. Reports can be printed, faxed, and e-mailed. 

3.8.1 UCI/CSI Report 

3.8.2 Contractor Report 

• Address Report 

• Mini Profile 

• Profile 

• Phone list by UCI/CSI 

• Comments - 
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3.8 J Bid Report 

• Bid Tab Report 

• Bid Call Report from A-Z 

• Bid Call Report by UCI/CSI Code 

• Bid Summary Report 

• Plans Transmittal Special Instructions Cover Sheet 

3.8.3. 1 User Activity 

• User Summary 

• User Audit Trail 

3.8.3.2 FaxActivity 

• Fax Summary 

• Fax Audit by Contractor 

• Fax History by Contractor 

• Fax status by Contractor 
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4 Glossary 







Addendum 


This document contains information relating to official changes in 
the bid. 


Architects/Engineers (A/E) 


Architects and Engineers 


Architect 


This primary actor has information and functionality specific to 
architecture company. 


Building Ptoduct Manufacturer (BPM) 


Building Product Manufacturer 


Construction Manager 


A professional who normally acts as a proxy for the owner or 
developer of a project. 


CSI codes (UCI/CSI Code) 


Construction Standards Institute — numeric codes which classify 
construction trades 


Engineer 


engineering company. 


General Contractor (GQ 


This primary actor has information and functionality specific to a 
general contractor company. 




on a project. 




engineering company. 


Plan 


This unstructured document represents the basic plan for a project 


Project 


This abstract class organizes the basic data and functionality of a 
project. This takes the trade classifications and company listings and 


Request for Information (RFI) 


This document represents a request for information that is passed 


Request for Proposal (RFP) 


This document represents a request for proposal. This document is 
architects and engineers. 


Scope Memo 


approach to a project. 


Specification 


This unstructured document represents the detailed specifications of 
a project. 


Subcontractor 


This primary actor has information and functionality specific to a 
subcontractor company. 


Supplier/BPM/Blue Printer 


This represents a registered company that does not need to store 
special information. 


Trade 


This refers to a particular building trade, such as a CSI code. 
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5 System Design 



5.1 Overview 

The system design leverages some common reoccurring patterns in the bidding business processes, 
and ultimately facilitates communication between business entities in a semi-structured manner. The 
design focuses on the collaboration of objects to facilitate communication. 



Figure 2: Convex Architecture Overview 
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5.2 Significant Business Events 

The majority of the system's business rules come into play when events occur in a system. What 
follows are the primary events the CONVEX system will manage in Phase One. 

5.2.1 New Project 

This event will be realized when a project author creates a new construction project in the 
CONVEX system. In Phase One this activity will primarily occur to facilitate the bidding process. In 
subsequent phases the activity will play a more significant role in the system's business logic. eBuilt 
envisions a new project being published to internal and external systems, as well as external systems 
publishing new projects into the bid management system. 

5.2.2 Invitation To Bid 

This event occurs when a project author submits an invitation to bid to contractors. 
5.23 Request for Information (RFI) 

This event occurs when a contractor submits an RFI to a project author. The project author will 
often respond with an addendum. 

5.2.4 Addenda 

This event occurs when a project author submits an addendum to contractors associated to a 
project. This event is often associated with a previous RFI event 

52.5 Scope Memo 

This event occurs when a project author submits a scope memo document to contractors associated 
with a project. 

5.2.6 Bid Submission 

This event occurs when a contractor responds to an invitation to bid event A bid is a statement 
representing the cost for goods and services. 
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5.3 USE-Cases 

53.1 Overview — Roles 



o 




Author Projects Manage Bids 
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53.2 Author Projects 
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5.3.4 Specify Location 




5.3.5 Select Bid Type 
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53.6 Select Labor Type 



o 




Select Prevailing Wage 



53.7 Select Preferences 
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53.8 From/To Template 



The ability to save and initiate a project K 




To Template 



53.9 Manage CSI Codes 




Import Code(s) from File Map Private Code to Public 
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53.10 Manage CSI Codes Interaction Diagram 
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53.11 Invitation To Bid 




Manage Contractors 




Bid specific information and ts>. 
instructions that appear on the 
Invitation To Bid. 



Document Manager 
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5.3.12 Manage Contractors 



o o 




Add Contractor 
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5.3.13 Manage Contractors Interaction Diagram 



53.14 Print Bid Reports 
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53.15 Send Documents 




Convex Technologies Functional and System Design Specification 
Phase One 
Page 37 



PRINT OF DRAWINGS 
AS ORIGIN A LLY FILE D 



5.3.17 Manage Bids 




Request Information 



53.18 Bid Management Interaction Diagram 
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53.19 Submit Bid 
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53.20 Decline Bid 
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53.21 Author Addenda 




5.3.22 Author Scope Memo 



o o 



Identify Project Identify Recipients 




Send Documents 

Document Manager 
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5.3.23 Request Information 




Document Manager 
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5 3.24 Select Geographic Preference 




5.3.25 Print Reports 



Print various reports associated with K 
managing the bid process and 
communications within it. 




Print Reports 



eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 43 



PRLNT OF DRAWINGS 



53.26 Visit Portal 
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53.27 User Login 

o o 



Authenticate Upsell Subscription 




53.28 Upsell Subscription 



X- 



of their current service level to the 



Upsell Subscription 



o — o 

Register Silver Membership Register Gold Membership 



eBufit 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 45 



PRLNTOF DRAWINGS 
AS ORIGINALLY FILED 




eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 46 



PRINT OF DRAWINGS 
AS ORIGINA LLY FILE D 



5330 Register Interaction Diagram 




5331 Administer Account 
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5.3 32 Administer Account Interaction Diagram 
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5333 Identify Account Type 




Select Engineer 
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53.34 Identify User Capability 




Can Participate in Bidding 
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5.335 Edit Company Profile 




Manage CSI Codes Manage Contractore 



53.36 Edit Company Info. Interaction Diagram 
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5337 Select Project Filters 




Select Project Filters Select Project Size 




Select Work Type s^wms 



5338 Register Silver Membership 




Edit Reference Edit Bond/Insurance 
Information Information 
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5339 Register Gold Membership 
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53.40 Object Model Overview 
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53.41 Project Object Model 
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5.3.42 Document Object Model 
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53.43 Company Object Model 
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5.3.44 Session Object Model 
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53.45 Roles Object Model 




5.3.46 Region Object Model 



Bid : String 
B&ame : string 



1 


Region 


1 


ZipCode 




JgZipCodes : StringQ 




gJZip : int 







lid : String 
| Name : String 
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5.4 Business Objects (Object Model) 

This outline represents the first design cycle. It is expected that the object model will evolve with 
subsequent implementation and design cycles. The primary key system objects are outlined with 
significant relationships detailed. 

5.4.1 Domain Object Model 



5.4.1.1 Private Attributes: 



•Object Name * 




CreationDate 


Date 


CreationOrigin 


int 


URL 


String 


5.4.2 Bid Withdrawal 




5.4.2. 1 Derived from ProjectDocumer 


t, DocumenfType 


5.43 InvitationToBid 




5.4.3. 1 Derived from ProjectDocumer 


t, DocumenfType 


5.4.4 Project 




5.4.4. 1 Private Attributes: 








Id 


long 


Tide 


String 


Location 


String 


BidDate 


Date 


BidTime 


Time 


Owner 


String 


Architect 


String 


Consultant 


String 


GeneralContractor 


String 


ProjectType 


int 


EstimatedValue 


float 


Description 


String 


Contact 


String 
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1 ProjectRoot 1 Projec 



5.4.5 ProjectDocument 

5.4.5. 1 Derived from Document 

5.4.6 Vendor 

5.4.6. 1 Derived from UserRok 

5.4.7 ScopeMemo 

5.4. 7. 1 Derived from ProjectDocument, DocumenfType 

5.4.8 Plan 

5.4. 8. 1 Derived from ProjectDocument 

5.4.9 Specification 

5.4.9. 1 Derived from ProjectDocument 

5.4.10 Addenda 

5.4. 10. 1 Derived from ProjectDocument, DocumenfType 

5.4.11 RequestForlnformation 

5.4. 11.1 Derived from ProjectDocument, DocumenfType 

5.4.12 RequestForProposal 

5.4. 12. 1 Derived from ProjectDocument 

5.4.13 Correspondence 

5.4. 13. 1 Derived from ProjectDocument, DocumenfType 

5.4.14 UserRole 
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5.4.15.1 Derived from Party 



5.4.15.2 Private Attributes: 







Login 


String 


Password 


String 


LastURL 


String 


LastLogin 


Date 


LoginDuration 


int 


Online 


boolean 



5.4.16 ProjectAuthor 



5.4. 16. 1 Derived from UserRo/e, PartyRo/e 

5.4.17 SpecialCategoty 

5.4.18 WorkType 

5.4.19 TtadeCode 

5.4.20 LaborType 

5.4.21 BidType 

5.4.22 Region 



5.4.22. 1 Private Attributes: 
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5.4.23.1 Private Attributes: 





*Obiect T '" T ' ; - ' -* ' ' 


id 


String 


Name 


String 



5.4.24 ZipCode 

5.4.24.1 Private Attributes: 









Zip 


int 



5.4.25 County 



5.4.25.1 Private Attributes: 







Id 


String 


Name 


String 



5.4.26 Notification 



5.4.27 Organization 

5.4.27./ Derived Jhm Patty 



5.4.27.2 Private Attributes: 







Id 


int 


ConvexRating 


int 


DBScore 


String 


WorkType 


WorkType 


WorkPhone 


String 


WorkFax 


String 


BidRange 


int 


LaborType 


LaborType 
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MWDVS 


String 


WorkLocation 


Regionfl 


Insurance 


String 


AnnualSales 


float 


Officer 


String 


ProjectReference 


String 


MarketingContact 


String 


Address 


String 


City 


String 


State 


String 


ZipCode 


String 


Phone 


String 


PrimaryContact 


String 


PrimaryPhone 


String 


SecondaryContact 


String 


SecondaryPhone 


bsst 1 


5.4.28 Contact 




5.4.29 Profile 




5.4.30 Contractor 




5.4.30. 1 Derived from Organi^ationType, PartyRole 


5.4.30.2 Private Attributes: 








License 


int 


Trades 


Tradefl 



5.4.31 MembershipType 

5.4.32 ProjectProfile 

5.4.33 Location 
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5.434 Capability 



5.4.34.1 Private Attributes: 







id 


int 


Name 


String 



5.4.35 OiganizationType 



5.4.36 DocumentList 

5.437 BidList 

5.438 Patty 



5.4.38.1 Private Attributes: 











id 


long 


Name 


String 




String 


Taxld 


String 


PhoneNumber 


String 


Address 


String 


City 




State 


String 


ZipCode 


String 


URL 


String n 


5.4.38.2 Public Operations: 






'ObJe^Paramete^ 




m 


hasRole 


Void 


Void 




addRole 


Void 


Void 


removeRole 


Void 


Void 


getRole 


Void 


Role 
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5.439 DocumentType 



5.4.39.1 Private Attributes: 



^Object Name > : •% , 




Id 


String 


Name 


String 


5.4.40 Message 
5.4.40. / Private Attributes: 






Status 


int 


Subject 


String 


DeliveryMethods 


int 



5.4.40.2 Public Operations: 



^bjeci MeSiBci' Name^ ' V 


,Object ParameteriTypeTS©^^ 




getStatus 0 


Void 


int 1 



5.4.41 Messenger 



5.4.42 Role 

5.4.43 Administrator 

5.4.43. 1 Derived from PartyRok 



5.4.43.2 Private Attributes: 



emmM 




Merchantlnfo 




SuperUser 


boolean 
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5.4.44 POPMessengerAgent 

5.4.44. 1 Derived from MessengerAgent 

5.4.44.2 Private Attributes: 







Host 


String 


Port 


short 



5.4.45 FaxMessengetAgent 

5.4.45. 1 Derived from MessengerAgent 

5.4.46 SystemMessengetAgent 

5.4.46. 1 Derived from MessengerAgent 

5.4.46.2 Private Attributes: 







MessageContainer 


String 



5.4.47 ProjectAuthoringProcess 

5.4.47. 1 Derived from BusinessProcess 

5.4.47.2 Public Operations: 
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5.4.48 BidCreationProcess 

5.4.48. 1 Derived from BusinessProcess 

5.4.48.2 Public Operations: 



:ObIect>/lethbd Name > 








createBid 


Void 


Void 


sendBid 


Void 


Void 



5.4.49 FaxCaptureMessengerAgent 

5.4.49. 1 Derived from MessengerAgent 

5.4.50 MessengetCoordinatot 

5.4.51 MessengerAgent 

5.4.51.1 Private Attributes: 





nmmmmm 




long 



5.4.52 GeneralCorrespondance 



5.4.52. 1 Derived from DocumenfType 

5.4.53 Bid 

5.4.53. 1 Derived from DocumenfType 

5.4.54 PartyRole 

5.4.54. 1 Private Attributes: 



msssmmm 




Name 


String 


Id 


int 
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5.4.55 UserPreferences 



5.4.55.1 Private Attributes: 





HomePageURL 


String 


DefaultPtoject 


String 


5.4.56 Capabilities 

5.4.56.1 Private Attributes: 






Id 


int 


Name 


String 


5.4.57 PtojectFiltet 

5.4.57. 1 Private Attributes: 


WorkType 


int 


LaborType 


int 


Trades 


Trade[l 


Location 


Region 


5.4.58 Historyltem 

5.4.58.1 Private Attributes: 




■HHHNMIi 


Record 


String 


TimeStamp 


String 


Who 


Party n 


ArcrdvePriority 


int 


Record 


String 


TimeStamp 


String 


Who 


Party 


ArchivePriority 


int 
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5.4.59 ProjectPreferences 



5.4.59. 1 Private Attributes: 








ShareBidList 


boolean 


ShareBluePrinters 


boolean 


ShareProject 


boolean f] 


5.4.60 Ttade 






5.4.60.1 Private Attributes: 










CSI 


int 


Description 


String 


Alternate 


String n 


5.4.61 TtadeMap 






5.4.61. 1 Private Attributes: 












CustomTradeCode 


int 


CSITradeCode 


int 


5.4.62 BusinessPtocess 






5.4.62. 1 Private Attributes: 












id 


int 


Name 


String 


5.4.63 UserSession 






A unit of work. 






5.4.63.1 Private Attributes: 








TimeCreated 




Date 
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5.4.64 Task 



5.4.64.1 Private Attributes: 




Name 



String 



Id 



int 



Ordinal 



int 



5.4.65 SMTPMessengerAgent 
5.4.65. 1 Derived from MessengerAgent 

5.4.66 OtherProcesses 

5.4.66. 1 Derived from BusinessProcess 

5.5 Physical System Design 

5.6 Data Architecture 

Below is the first design of the database schema. As the object model evolves the schema will 
change and additional implementation level tables will appear (such as, join tables). It is also 
expected that database architects will optimize and refine the schema during development. 



Convex Technologies Functional and System Design Specification 
Phase One 



eBuilt 



Page 71 



PRLNT OF DRAWINGS 
AS ORIGINAL LY FILED 



5.6.1 Schema Model 




5.6.2 Logical Entity/ Attributes Overview 







* r L . 1^ 


T_Administrator 


No 


Merchantlnfo 


No 






ThirdPartyLoginlnfo 








SuperUset 




T_BusinessProcess 




BusinessProcessId 








id 








Name 








Tasks 








CurrentProcess 




T_Contractor 




Trades 








Regionld 








license 




T Document 




Documentld 








CreationDate 
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f -BrfUiv ^iafi^ tar.© 1 ana?; aXuii^k? ^sat 






URL 








CreateOrigin 








Type 








Document 








OwnerAuthor 




T_DocutnentType 




DocumentTypeld 








NamC 
















— 

Type 




T_HistoryItem 




Historyltemld 








Record 








TimeStamp 








Who 








ArchivePriority 








AuditTraii 




l_Message 




Messageld 








Status 








Subject 








DeliveryMethods 








Messages 








Document 








MailTo 








MailFrom 




T_MessengerAgent 




MessengerAgentld 








Id 








MessengerCoordinatorld 








Messages 




T_MessengerCoordinator 




MessengerAgentld 








Messages 








MessengerCoordinatorld 




T Organization 




ConvexRating 








DandBScore 








WorkType 








WorkPhone 








WorkFax 








BidRange 






1 LaborType | 
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MWDVS 








WorkLocation 








UserField 








Insurance 








AnnualS ales 








Officer 








ProjectReference 








BusinessReference 








MarketingContact 








Address 








City 








State 








ZipCode 








Phone 








PrimaryContact 








PrimaryPhone 








SecondaryContact 








SecondaryPhone 








Trades 








TradeMap 








Filter 








AuditTrial 








DefaultPreferences 








UserSession 








Users 








Contact 




T_Party 




Partyld 








Id 








Name 








Email 








Taxld 








Phone 








Address 








City 








State 








ZipCode 








URL 
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I 


t 0-itv 






Roles 








OwnerAuthor 








MailTo 








MailFrom 








Owner 




T_PartyRole 




PartyRoleld 








Name 








Id 








Roles 




TJPOPMessengerAgent 




Host 








Port 




T_Project 




Projectld 








Id 








Tide 








Location 








BidDate 








BidTime 








Owner 








Architect 








Consultant 








GeneralContractor 








ProjectType 








EstimatedV aluation 








ScopeDescription 








Contact 








RootProject 








OwnerAuthor 








BidList 








Project 








Parent 








AuditTrial 








Preferences 








BluePrinters 




TJProjectFilter 




ProjectFilterld 








WorkType 








LaborType 








Trades 
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; 











Location 








Filter 




T_ProjectPreferences 




ProjectPreferencesId 








ShareBidList 








ShareBluePrinters 








ShareProject 








DefaultPreferences 




TJtegion 




Regionld 








ZipCodes 








Contractorld 




T_SystemMessengerAgent 




MessageContainer 




T Task 




Taskld 








Name 








Id 








Ordinal 








SubTask 








Tasks 








CurrentTask 




T_Trade 




Description 








Trades 








TradeMapId 








CSI 








Tradeld 




T_TradeMap 




CSITradeCode 








TradeMap 








Tradeld 








CustomTradeCode 








TradeMapId 




T User 




Login 








Password 








LastURL 








LastLogin 








LoginTime 








Online 








Preferences 








Users 








Contact 
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UserObject 




T__U s erPtef erences 




UserPreferencesId 








HomePageURL 








DefaultProject 








Preferences 




X UserSession 












TimeCreated 








CurrentTask 








CurrentProcess 








Owner 








UserSession 








UserObject 





5.63 Partitioning 



Distribution of the databases will be addressed as the system scales. It will be assumed that multiple 
database instances will eventually exist as user transaction rates increase. Application servers will play 
a key role in reducing database resource usage, ultimately directing load based on user traffic to 
distinct database instances. 

6 User Experience 

A real-world prototype should ideally exist, which will be the basis for the user interface design. It is 
expected that UI design will be iterative due to: 

• The complexity (unsophisticated nature) of the user-base 

• The need for significant functionality with minimal user burden 
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6.1 Story Boards for Bid Manager 

6.1.1 Create New Bid 

6. 1. 1. 1 Screen 1 
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6.1.1.2 Semen 2 
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6. 1. 1.3 Screen 3 
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6.1.1.4 Screen 4 
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6. 1. 1.5 Screen 5 
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6. 1. 1.6 Screen 6 
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6.1.1.7 Screen 7 
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6.1.1.8 Semen 8 
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6.1.2 Invitation to Bid 

6.1.2.1 Screen 1 
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6.1.2.2 Smen2 
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6.1.2.3 Semen 3 
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6.1.2.4 Semen 4 
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6.1.2.5 ScreenS 
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6. 1.2.6 Screen 6 
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6.1.2.7 Screen 7 
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6.1.2.8 Screen 8 
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6.1.3 Create and Send Documents 

6.1.3.1 Screen 1 
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6.1.3.2 Screen 2 
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6.1.3.3 Screen 3 
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6. 1.3.4 Screen 4 
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6.1.3.5 ScreenS 




Mare - 

t#v/zo vaci f exe.n- tvci, ere, 

/if /IrTSWlSl*?. ?r ffO **4f 

re £f*/ise-/zr .X3oe t . xct, 
ere, ro f*x z>oe.t/r*7£/vrs. 



se*,p . hoc Tt>u*£- a>sk> r 




Convex Technologies Functional and System Design Specification 
Phase One 
Page 98 



PRLNT OF DRAWLNGi 
AS ORIGINA LLY FILE D jjj ~ + 



6. 1.3.6 Screen 6 
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6.1.4 Fax Capture 

6.1.4.1 Screen 1 
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6.1.4.2 Screen 2 
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6.2 Site Map 






1— 




la— 


1 — 





















eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 101 




3 



K 



i 



PRINT OF DRAWLNGi 
AS ORIGINA LLY FILE D 




eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 102 




eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 103 



PRLNT Of DRAWLNGi 
AS ORIGINA LLY FILE D 




eBuilt 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 104 



PRINT OF DRAWINGS 
AS ORIGINA LLY FILED 




http://www.ebuilt.net/cortvex/ 
pnojects/comm_engine.html 



• 



http://www.ebuilt.net/convex/ 
projects/ 
comm_sngine_faxhtmi 



§ 



http://www.ebuilt.net/convex/ 
projects/ 
comm_engine_email.html 



• 



httpV/www.ebuilt.net/convex/ 
projects/ 
comrn_engine_data.htrnl 
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7.2 System Tiers 




7.3 Detailed Systems Architecture Features 

The network will be built with the following items. 

73.1 No Single Point of Failure 

• Redundant hardware 

• Redundant local loop providers 

• Redundant ISPs 

• High performance internal network 

• Switch-based 

• Gigabit or better backbone 

• High performance Internet connection 
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• Multiple connections to Internet 

• Connect only to major backbones 

• Overbuilt with excess capacity for peak demand 

• Use cache servers or services for optimized performance 

73.2 System Architecture 

The overall system architecture has three zones with the following characteristics: 

7.3.2. 1 The Internet Presence Zone: 

• Many external clients 

• Support vagaries of Internet "weather" 

• High level of security/ fortification 

• Limitless or near limidess scaling 

• No unique data in Internet connection zone 

• Isolates business logic zone from Internet 

• Low latency server and network performance 

• High capacity support for many concurrent clients 

7.3.2.2 The Business Logic Zone 

• Runtime unique data replicated 

• Privileged data systems access 

• No external clients 

• Vertical and horizontal scaling 

• Multiple business logic systems can execute concurrently 

• System and network management 

7.3.2.3 The data systems %one 

• Storage of all unique data stores 

• Redundant storage devices 

• Hardened data store servers 

• Only accessible from the business logic zone 

• Centralize data backup and archival 

• Disaster recovery support 

73.3 Database Architecture 

The physical database architecture is based on meeting the business requirements for very high 
capacity and very low latency (high performance). This will dictate the following: 

• High performance/high availability storage 
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• Hardware RAID storage systems with support for redundant controllers and interfaces 

• Multiple CPU servers with support for large installed memory 

• Typically Enterprise class Unix servers with 64bit memory addressing to support greater than 
8GB of memory 

• Possible exploitation of in memory databases 

• Use such a product in front of traditional relational database 

• Exploit object databases as appropriate 

• As dictated by logic or data types 

73.4 Management Systems 

There are basic themes or strategies to the management system that will be adhered to. The 
CONVEX system will have system and application management, and they system will have network 
management. Systems will be built or purchased to deliver these goals as efficiently as possible. 

7.3.4. 1 Focus on managing business deliverables rather than resources 

Using a car as an analogy — the speedometer measures the business deliverable, and the tachometer 
measures a resource used to gain travel. . .the engine RPM. It is common to deliver a system or 
software package that includes the tachometer, but often litde or no consideration is given to the 
speedometer. 

7.3.4.2 Management systems should be lightweight 

The management system needs to be lightweight and simple to manage. 

7.3.4.3 Automation, Automation, and Automation 

Computers are devices for automation. Therefore, the systems that manage computers should also 
be automated. This dictates the architecture. 

7.3.4.3.1 Automation requires correlation. 

Automation requires the correlation of system information to enable automated intelligent decisions 
and actions. 

7.3.4.3.2 Correlation requires centrahzation 

• Management data must be centralized to allow for intelligent correlation. There are two disparate 
data sources. These data sources could be correlated separately and with their respective 
correlation results used for cross-correlation. 

• System and application events need to be centrally visible, collected and correlated. This data is 
best known as the source data for alert notification. 
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• System and application statistics need also to be centrally visible, collected, correlated and 
archived. This data is best known as the source data for performance graphs and statistical 
analysis. This data, via thresholds, is also used for alert notification and event correlation. 

7.3.4.4 Web-based interfaces 

The preferred interface to the management systems is the browser. 

7.3.4.5 Open standards. 

Proprietary standards and interfaces are to be discouraged. 

7.3.4.6 Performance 

Performance characteristics vary by zone and role 

7.3.4.6.1 Internet Presence Zone: 

This zone is usually built with a number of identical, low-cost servers. Often these are single- 
purpose servers replicated many times for capacity and fault tolerance. Disk usage here is minimal. 
System tuning is performed to optimize the servers for the role that they perform. 

7.3.4.6.2 Business Logic Zone: 

Compared to the Internet presence zone, these machines tend to be slightly larger, but p rimarily 
remain single-function servers replicated for fault tolerance and capacity. Disk usage remains 
minimal, but memory and CPU usage is greater for each machine. System tuning is performed to 
optimize the servers for the single role that they perform. 

7.3.4.6.3 Data Systems Zone 

This zone is inhabited by fewer large servers, and in some cases, multifunction servers. This need 
requires high disk IO capacity, large memory footprint support (preferably 64bit memory 
addressing), and SMP support for multi-CPU servers. System tuning is more complicated (for 
multifunction servers), hence the need to overbuild these critical servers with excess CPU and 
memory. 

7.3.5 Redundancy and Scalability 

There are two strategies for redundancy and scalability in this system architecture. 
7.3.5. 1 N+X Server architecture 

The Internet presence and business logic zones do not have a large amount of unique data, so they 
are well suited for N+X scaling. In general, the server systems consist of N+X identical servers 
supporting the identical business functions. The capacity needed of the system requires N servers, 
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but X additional servers are installed for excess capacity and protection against a server failure. 
Should a server fail, some capacity is lost, but there is no impact to delivering the business function 
to the customer. 

7.3.5.2 The Big N architecture 

The data systems zone includes large amounts of unique data. This dictates large, hardened servers. 
These servers tend to grow in size rather than number. The server platforms are chosen to minimize 
or eliminate single points of failure. Disk subsystems have protected (RAID) disks and support for 
controller and interface fail-over. Some databases might need to be built for complete fault-tolerance 
and recovery. This will require clusters, database replication, or some other scheme to guarantee 
uninterrupted access to this unique data. 

7.3.5.3 Security 

The three system zones also represent three different security zones: 

• The Internet presence zone is the only zone direcdy accessible from the outside world. IP traffic 
is limited to what is necessary for the business deliverable. Individual machines are hardened and 
locked down for tight security. These machines are also closely monitored for break in attempts, 
denial of service attacks, and unauthorized alteration. 

• The business logic zone is the only internal zone accessible from the Internet presence zone, and 
traffic between these two zones is closely controlled. These machines will also be hardened and 
locked down for tight security. These machines are not directly accessible from the Internet 
since they do have some runtime unique data. This zone is the only zone that can connect to the 
data systems zone. Since this zone has visibility into the other two zones, the management and 
security systems are located here. 

• The data systems zone is only accessible from the business logic zone. Any other connectivity 
will be stricdy limited and monitored. For further measure, these machines will also be hardened 
and locked down for tight security. 

7.3.5.4 Facilities 

There will most likely be two types of facilities: 

• The central data center must be built as a standard, mission-critical data center with UPS and 
generator backed power, redundant AC, fire suppression system, a premises or physical security 
system, excess space to accommodate rapid growth, and staging space for system upgrades and 
new technology. 

• The distributed fax/cache complexes will likely be housed at collocation facilities that are built 
similar to the central data center, but these facilities will be built and managed by a vendor. 

7.3.5.5 Centralized Internet Architecture 

The cost of managing distributed data centers is much greater than that of centralized data centers. 
Distribution should be closely aligned with business requirements. For CONVEX, the requirement 
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is to minimize facsimile costs and to ensure high performance/low latency Web site performance. 
The combination of a centralized data center with distributed content servers and fax servers will 
meet the business requirements with the lowest possible cost. Disaster recovery can be handled 
using outsourced disaster recovery services, or if financially justifiable, by the addition of a hot 
backup data center. Having centralized data centers does not preclude having staff at remote offices. 
This document only addresses the system and network architecture. 
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7.3.5.6 Distributed Fax Services 

Once cost justification is reached to replace fax services with a fax server network, fax servers will 
be distributed in a manner to minimize telephone toll charges. This would also have to be compared 
against the cost of centralizing the servers and paving negotiated, bargain basement, long distance 
charges. Internet connectivity would be the transport medium for fax server communications and 
the high cost of a private WAN should be avoided. 
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7.3.5. 7 Normal Centralized Web Hosting 



Normal Centralized "Web Hosting 
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7.3.5.8 Web Hosting via Cache Network Service 




Content from replicated web site is delivered locally (transparently) to the users front the nearest cache server, 
requests. 

— t- Only the cache servers communicate with origin servers, at web hosting. Content is replicated as users request it. 

eBuilt 

7.3.5.9 Internet Connection Zone Characteristics 

• Many external clients 

• Support vagaries of Internet "weather" 

• High level of security/ fortification 

• Limitless or near limitless scaling 

• No unique data in Internet connection zone 

• Isolates business logic zone from Internet 

• Low latency server and network performance 

• - High capacity support for many concurrent clients 

7.3.5. 10 The Business Logic Zone 

• Runtime unique data replicated 

• Privileged data systems access 

• No external clients 
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• Vertical and horizontal scaling 

• Multiple business logic systems can be parallelized 

• System and network management 

7.3.5. 1 1 The Data Systems Zone 

• Storage of all unique data stores 

• Redundant storage devices 

• Hardened data store servers 

• Only accessible from the business logic zone 

• Centralized data backup and archival 

• Disaster recovery support 

7.4 Collocation Overview 

This issue is often decided by personal philosophy and/or comfort level. Financially, the costs can 
be presented to favor and disfavor system collocation over self-hosting. It benefits any new venture 
to simply follow the patterns and trends in the industry. The most prevalent and pertinent pattern 
has been for a firm to begin small and self-hosted in inappropriate conditions. The company grows 
and decides to rectify the situation and chooses to use collocation to preserve cash flow and move 
quickly. These firms subsequendy are successful, grow very large, and tend to desire the relocation 
of their systems to their own data center for various business related reasons. Technically there is 
almost never a reason not to use collocation. The decision should be based on business 
requirements. 

7.4.1 Recommended Plan for Hosting 

Plan on starting out with collocation maintaining the understanding and planning to support moving 
the system in-house (at some major point in the system's growth-curve). Use this time to prevent 
committing any capital costs related to the data center prior to experiencing the dynamics of the 
system, its changes, and its growth. 

As the company's revenues are generated by the system, in time, it is likely that the contractual 
agreement with the collocation vendor will no longer provide the comfort level desired in delivering 
the level of service customers' require. The need to differentiate from the competition, the 
sensitivity of data stored in the system, and the shear size of the system will favor moving the heart 
of the system in-house to a centralized, company-controlled data center. The front-end may or may 
not move in-house, but the use of a cache network will always represent a collocated, outsourced 
front-end system 

Yahoo! best exemplifies this model. Yahoo! maintains strict control of the systems that generate 
dynamic content, but static content and ancillary services are collocated or outsourced to Yahoo! 
subsidiaries. 
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7.42 Major Hosting Providers 

7.4.2.1 AboveNet 

Strong data center and strong network, but not in Southern California, yet. 

7.4.2.2 InterNap/ Level 3 

Very strong network, data center not manned, Irvine in 11/99. 

7.4.2.3 Frontier GlobalCenter 

Very strong hosting services and network, data center in Anaheim 11/99. 

7.4.2.4 Exodus 

Very strong hosting service, data center in Irvine (currently our of space) and El Segundo. 

Both InterNap and AboveNet rely on partnerships to provide value-added services. Currently 
AboveNet's partners are stronger than Internap's, and thus, they are listed first. InterNap is moving 
aggressively in this area and may be more strongly positioned by the time a choice is made. 
GlobalCenter and Exodus have concentrated on hosting services at the expense of their network 
engineering, and many of their customers are addressing that situation by requiring Exodus or 
GlobalCenter to allow InterNap to provide connectivity to their collocated systems. 

7.5 Staffing for System Operations Support for Phase One Rollout 

Staff will be necessary for customer support and is not addressed in this document. The staffing 
(described below) is to support mission-critical systems with no acceptable downtime, and is 
intended to grow with the system. Additional staff can be filled with mid-level and entry-level 
candidates as the existing staff grows in experience and skill set. There may be a need for specialized 
skill-sets as the system grows, such as: 

• Network engineers 

• System management specialists 

• Disaster recovery specialists 

• Capacity planning specialists 

• And more 

These needs will be based on the strengths and weaknesses of the existing staff, and will be gready 
influenced by the dynamics of the system's evolution. 
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7.5.1 System Operations Support Responsibilities 

System operations support owns system availability and performance, such as: 

• Monitoring system performance. 

• Handling all necessary system interventions. 

• Handling all normal system maintenance activities. 

• Version upgrades, patches, file system maintenance, and log analysis. 

• Handling all vendor fix coordination. 

• Installing any new software and/or systems. 

• Managing system capacity. 

• Interfacing with all vendors. 

7.5.2 Phase One Staffing and Roles 

7.5.2. 1 System "Engineers 

Responsible for building and configuring all hardware and software systems. 

7.5.2.2 System Administrators 

Typically, this is staffed by senior operation system administrators. 

7.5.2.3 Database Administrators 

Responsible for building, configuring, and administrating all databases, as well as engineering data 
availability systems (such as, backup, archive, and recovery). Typically, a senior database 
administrator with some system administration experience is ideal. 

7.5.2.4 System Operators 

Responsible for monitoring and administrating systems engineered by the system engineers and 
database administrators. Typically, this is staffed by mid and entry-level system and database 
administrators. 

7.53 Recommended Staffing Level for Phase One 
7.5.3. 1 System Engineers 

One senior Unix System Engineer with Internet and networking experience. 
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7.5.3.2 Database Engineer 

One senior Oracle Database Engineer with Internet experience. 

7.5.3.3 Earlj Shift Operators 

One mid-level Unix system admin with some database knowledge, and one entry-level Unix system 
operator. 

7.5.3.4 Late Shift Operators 

Two operators for an early shift operations staff. 

7.5.3.5 After-hours I weekend coverage 

Staffed with either entry-level Unix system administrators, or staffed (by contract) with a collocation 
vendor or third-party support organization. 



Convex Technologies Functional and System Design Specification 
Phase One 
Page 121 



eBuilt 



PRLNT OF DRAWihGi 
AS ORIGIN A LLY FILE D 



8 Third-Party System Components (Web E-mail/PIM/Chat) 
8.1 Overview 

This information is provided as a rough guide to products that the CONVEX site might utilize. The 
list is not final. Some products have been evaluated, but not all. Factors used in selecting potential 
candidates include: 

• Product features meet functional requirements. 

• Product has a configurable look and feel to facilitate blending into the CONVEX Web site look 
and feel. 

• Application utilizes scalable technology and architecture. 

• Application aclministration and user interfaces are appropriate for the skill level of users 
interfacing with those components. 



8.2 Web E-mail and Personal Information Management (PIM) 











TTC A XT-* 


• 1 to 2499 mailboxes 
are $1.40 a box per 
month ($3500) 

• 2500 to 4999 
mailboxes are $1.20 a 
box per month 
($6,000) 

• 5000 to 9999 
mailboxes are $1.00 a 
box per month 
($10,000) 

• 10000 and up are 
$0.80 a box per 
month 


• Add/remove 
accounts 

• Activity 
Reports 

• Branding 

• Seamless API 


• Junk Mail filter 

• Vacation reply 

• POP3 e-mail 
collecting, 

• Scheduling of 
reminders-B- 
days, etc. 


• Netscape 

• American 
Express 


Commtouch 


• 1 to 10000 mailboxes 
are $2100 per month 

• 10001 to 20000 
mailboxes are $3400 
per month 

• To include the 
calendar function is 
an additional $0.60 a 
box per year ($6000 
per 10000 mailboxes 
per year) 


Similar to USA 
Net 


Similar to UAS Net 


• Discovery 
Online 

• Seventeen.com 

• Fortune Qty 

• Excite 

• Netopia 

• Colleges.com 

• Headbone.com 
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8.3 Web Chat 
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Web 
Crossing 


• 250 concurrent users 
-$895 

• 20,000 users + 
messages add $695 

• 200,000 users + 
messages add $2,495 


• Browser 
based admin 

• Email 
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• Display 
banner ads 

• Read-only 
conferences 

• Multi 
platform 


• HTML based 
- low tech feel 

• Custonuzable 

• Search engine 

• Profanity filter 


• CNN 

• CitySearch 

• C | net 
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• NY Times 


DigiChat 


• Chat $995 

• Moderated Chat 
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Remote admin 
Multi platform 


Java client/ slick 
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• Upload 
personal icons 

• Simple to use 

• Profanity filter 


• Cable and 
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• Matchmaker.com 

• The Internet 
Movie Database 
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University 

• Scientific Atlanta 


Webmaster 


• $1,500 for 1,000 
concurrent users 

• Scribe (Transcript 
module) $495 

• $4,295 for 10,000 
concurrent users 




Java client 


O'ReilyWebBoard 
utilizes the 
conference room 
component 



8.4 Web Application Development Platforms/Databases 
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9 System Components List (ROM Pricing) 

Below describes hardware and software for a best-of-breed portal site, which is fully redundant (high 
availability) with a mainframe class system. 

9.1 System Component Overview 

This information is provided as a rough guide for planning purposes only. The number of systems 
required for each type will vary based on factors, such as: 

• The number of Web hits the site will receive during peak hours. 10 million hits/day (or 700,000 
hits/peak hour) is used as the starting point for calculations. 

• The number of transactions that will be generated as a result of Web hits (eBuilt estimates two 
transactions per second). 

• The amount of fault tolerance desired. 

• Application complexity. 

9.L1 Front-End Systems (4) 

• Sun single processor commodity servers. 

• IBM Websphere (Web Server component includes SSL support). 

• Cost Est $1,000 per server = $4,000 total 

• Hardware Assist for SSL (card per server or via Ethernet switch) 

• Cost Est $5,000 per server = $20,000 total 

• System Metrics and System Management agents. 

• Sample Hardware System Cost: 

• Sun Netra Tl-360 512MB memory single 9GB drive (4x) $7,000 

• Server Hardware: ~ $28,000 

Total approximate cost for front-end systems: $55,000. 

9.L2 Application Servers (4) 

• Sun mid-range (2) CPU servers. 

• BEA Web Logic Application Server or IBM Websphere. 

• Cost Est $15,000 per CPU = $120,000 

• System Metrics and System Management agents. 

• Sample Hardware System: 

• Sun E250 2GB memory 2CPU, FibreChannel intfc $30,000 

• Shared Raid Storage Array $20,000 

• Total 4 Servers and 2 Arrays = ~$ 1 60,000 

Total approximate cost for application servers: $280,000. 
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9.13 Database Servers (2) 

Upgradeability and reliability are key requirements. 

• Sun Enterprise class Servers (supporting 8+ CPUs and 8+ GB RAM). 

• External disk subsystems (RAID 0+1 -mirrored stripe). External disk would be shared for fault- 
tolerance if multiple database servers and high availability features were deployed using the 
Enterprise version of Oracle Database Server. 

• Oracle 8i Enterprise Database Server with HA options. 

• Cost of 50 Concurrent Users $ 1 00,000 (x2 for the redundant system) = $200,000 

• System Metrics and System Management agents. 

• Sample Hardware System: 

• Sun Enterprise E5500 with 4CPU's and 4GB RAM (initial) = $170,000 

• Enterprise Storage Subsystem 100GB (initial) = $40,000 
• Total Two Systems with 2 Storage arrays = $420,000 

Total approximate cost for database servers: $620,000 

9.1.4 Management Systems (4) 

To monitor system performance and availability and perform global management tasks. 

• SNMP monitoring and reporting tools (HP OpenView, IBM Tivoli/NetView, and so on). 

• Estimated Cost = $100,000 

• System availability monitoring software tools. 

• Estimated Cost = $80,000 
Total software cost: $180,000 

• 2 Intel commodity PCs as workstations. 

• Estimated Cost = (2x) $2,500 

• Sun 2 CPU management server. 

• Sun 2 CPU system monitoring and data collection server. 

• Sample Hardware System: 

• Sun E250 with 2CPU's 2GB RAM, FibreChannel Interface (2x) $30,000 

• Shared Storage Array $20,000 (shared between the (2) 2 CPU systems) 

Total hardware cost $85,000 

Total approximate cost for management systems: $265,000 

9.1.5 Network Equipment 

• Cisco Catalyst Ethernet switches with Gigabit Ethernet uplinks for backbone. 

• Est. Cost $50,000 (x4) total $200,000 

• Cisco 75XX class routers with appropriate interfaces and min. 96M of memory. 
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• Est. Cost $100,000 (x2) total $200,000 

• 2 Cisco Local Director 420s for load balancing. 

• Est. Cost = $20,000 (x2) total $40,000 

Total approximate cost for network equipment $440,000 

Approximate total for all the identified hardware and software: $1,660,000. 
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1 0 Third Party Technologies 

Below describes technology that will be required for CONVEX system development. 

10.1 Publish/Subscribe Messaging Middleware (MOM) 

Publish/Subscribe messaging middleware is a key technology for building robust, scaleable systems. 
The CONVEX system will leverage MOM to: 

• Asynchronously broadcast documents to services 

• Communicate status 

• Common messaging bus to interface and integrate other systems 

• Broadcast news to front-end servers 

• Broadcast project status to front-end servers , 

• Send content updates to multiple servers 

• Update a user's state across several servers 

This technology will be the primary glue between systems. Common messaging formats and 
semantics will be defined between systems and subsystems. 

10.1.1 Key Manufacturers 

10. 1. 1. 1 TIBCO TIB/RV (hup:// www.tibco.com) 

• Technology used by NASDAQ, Reuters. 

• Pioneer of Publish/Subscribe subject-based addressing. 

• CISCO implements TIBCO reliable multicast technology in their hardware. 

• Co-Author OMG messaging standard. 

• Network Management Hooks. 

10. 1. 1.2 Talarian SmartSockets (http:/ / www.smartsockets.com) 

• Aerospace roots, deployed by MCI for per call fraud detection. 

• Employ's GlobalCast's Reliable Multicast Technology (Lucent's RM technology) . 

• High burst rates due to message coalescing. 

• Strong monitoring tools. 

10. 1. 1.3 Vitria (http://www.vitria.com) 

• Technology developed by former TIBCO and Sun engineers. 

• Leverages object technology. 

• Next generation technology. 

• Several key customers. 
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10.1.1.4 Global Cast (http:/ / www.gcast.com) 

• Technology developed by Lucent. 

• Leading edge RM technology (reliable multicast). 

• Next generation technology. 

• Presendy C/C+ + API only? 

10. 1. 1.5 IBM MQSeries Messaging (http: I jwww.ibm.com) 

• Leading traditional MOM. 

• Popular in EAI market 

• Mature implementations available on legacy hardware. 

• Strong Java bindings. 

• Moving into P/S world. 

• Co-Author OMG messaging standard. 

10.1.2 Broadcast Faxing (IP or Internet Originated) 

10.1.2.1 Key Players: 

1 0. 1 .2. 1 . 1 Premiere Technology (formerly Xpedite) 

• Claims to be largest Broadcast fax entity. 

• 20,000 parallel faxing capability. 

• Willing to develop custom interfaces. 

• Seems to be a feature fit. 

• Sales folk visit and call back! 

10.1.2.1.2 UUFAX 

• Key Internet backbone player. 

• Unknown volume and capacity. 

• Does not return calls. 

• National per page rate .07. 

10.1.2.1.3 AT&T IP Fax Solutions 

• Leverage large national backbone. 

• Unknown volume and capacity. 

• Two calls with promises to call back. . .and no call-backs. 

10.1.2.1.4 TGIVAN (PopStar IP Fax) 

• Unknown player. 

• Questions in route, no answers yet. 
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• Have demo access to Web site service. 

10.1.3 Document Imaging Software (ICR and TIFF Processing) 

10.1.3.1 Key Players 

• Kofax 

• Filenet 

• Imagelib 

• Accusoft 

• Xerox ICR Forms 

• Wang 

• Xionics 
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11 Functional Matrix 



The Functional Matrix is for managing and summarizing project expectations and goals. 







Introduction and Overview * ^ 


i. 


The CONVEX system will bring the construction business into a 
complete, automated online system that integrates project management, 
bid management, and supply chain functions in a centralized Internet 
system. 
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2. 


Ultimately, the CONVEX system will be the catalyst for a new business 
model that changes or eliminates common roles in existing business 
models (paradigm shift), saving the industry billions in overhead by 
facilitating resource reduction, time, and efficient resource management. 
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12 Appendices 

Convex Functional Specifications— Phase I 



Prepared By: Larry Wares 

State of document: Draft #1 
Phase of project: Phase I 



The Convex Portal will ultimately become the "Yahoo" or "AOL" of the 
Introduction Commercial Construction Industry. The ultimate end-state of Convex is to 
become the place where the construction community comes to do business - 
buying, trading and acquiring new business and industry-related information. 

Web adoption will be slow at the targeted mid-sector or subcontractor level; 
therefore, a phased implementation plan that drives eyeballs into the site for 
new business at little or no service fee will drive the business strategy. 



Phase I consists of creating a communication service and portal that enables 
general contractors to communicate via fax and e-mail with subs and suppliers. 

Phase II expands the capabilities of the portal to enable the exchange of plans, 
specifications and other bid-related documents among Phase I users. 

Phase III expands the capabilities of the portal to procurement and purchase 
management for building materials and products - including auctioning of 
surplus products and materials. 



General Contractors 

Targeted Users 

Subcontractors 

Suppliers/Distributors/Building Product Manufactures (BPM) 
Owners (Developers, Government Agencies, etc.) 

Additional 
Users 

Architects 

Engineers 

Blue Printers 

Industry Consultants 

Insurance and Bonding Agencies 

Financial Institutions 
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Other Construction Service-related firms 
System Administrators 

Convex Users 

Database maintenance personnel 

Sales and training personnel (demonstration data) 

Technical support staff & development engineers 



Scope of Features Generally speaking, the heart of Phase I will be the "BidFax"-like features. 

- Overview General contractors will use the portal to broadcast faxes and e-mails to a 

specified list of bidders. Bidders typically are made up of subcontractors who 
are categorized by industry standard trade codes. Recipients will either RSVP 
by fax, e-mail or by direct entry into the portal — the latter being the ultimate 
goal. Larger subcontractors will perform many of the same solicitation effort 
of a G.C. to suppliers and distributors; therefore, forwarding information 
within a secured portal creates a high value proposition. When Phase II is 
complete the portal will offer all participants secured access to plans, 
specifications and other bid-related documents. Phase I's two primary features 
will be BidFax-on-the-web linked to a public database of subs and suppliers. 
The portal must be engineered to scale to Phase III and must be designed as a 
user-smart interface (front-end is look and feel and content specific to industry 
segments — electrical subs see electrical stuff, etc.). 

Scope of Features 

- Detailed 



Directory An industry-specific directory of Architects, G.C.'s, subs, suppliers, wholesalers, 

distributors, BPM's and other service-related consultants will feed the bid 
solicitation capabilities required by the G.C.'s. The database will contain 
approximately 1.5 million records. Subcontractor records make up the bulk of 
the database at approximately 800,000 records, the balance of which is a 
mixture of the above. We will offer three levels of database services as follows: 



Bronze - Basic listing (Free) 

Silver - Enhanced Listing (Pay level 1) 

Gold - Enhanced listing & Custom Page (Pay level 2) 

Basic listings will contain approximately 20-25 fields of data, the most critical 
being trade reference/CSI code(s), preferred type of work and geographic work 
preference. It is important to note that the physical location of the sub may not 
be related to the geographic work preference(s). Utilization of pick-lists and 
geography maps to associate consistent data with records will be required for 
ease of use. The following list of fields represents a typical Bronze record: 

1 . Company Name 

Bronze Listing 2. Work Phone Number (Duplicate search upon entry) 

3. Contact 1 

4. Contact 2 

5. Work Fax Number 



PRLNT OF DRAWINGS 
AS ORIGIN A LLY FILE D 



6. Mobile Phone 

7. Pager 

8. E-mail 

9. WebSite 

10. Address 1 

11. Address 2 

12. City 

13. Sate 

14. Zip 

15. Bid Range (2 Pick lists - Min. value and Max value - overall job size, not 
trade size) 

16. Labor = Union, Open Shop, Open Shop/Prevailing Wage 

17. M/W/D/V/S (Minority, Women, Disadvantaged, Veteran, Small 
Business) 

18. Trade(s) (Pick-list &om master UCI/CSI format (See list attached) 

19. Geographic Preference (Use map to identity wide geographic range or 
narrow down to one or several cities.) 

20. WorkType (Use pick list supplied by Convex, ie., Schools, Industrial, 
Retail, etc.) 

21. Trade x-reference (Used to associate master UCI/CSI list with in-house 
list) 

22. User Field 1 

23. User Field 2 

24. User Field 3 

The Silver listing adds a few more fields that represent performance, credibility 
and reference checking capabilities for automated due-diligence. Silver listings 
have priority over Bronze when a G.C. is picking subs for a new bid (Gold list 
Silver Listing before silver, silver before Bronze). The priority listing capability is one driver 

of the business model. The added fields for Silver are as follows: 

1 . Bonding & Insurance Information (Capacity, Agent, Rating) 

2. Annual sales volume 

3. Number of employees 

4. Officer contact (3 contacts) 

5. Marketing contact (2 contacts) 

6. Financial contact (2 contacts) 

7. Field contact (2 contacts) 

8. Emergency contact (3 contacts) 

9. Credit History (D&B or equal - Possible link to credit services burrow) 

10. Project reference (Previous successful projects & links) 

11. Business References (Up to 5 key references & links to e-mail) 

12. Convex rating (Future quality rating system managed by Convex) 

The Gold listing contains a fully maintained custom page designed by Convex. 
The personalized page will contain standards and service points designed around 
the ultimate end-state of the Convex service portal This may include financing, 
banking, marketing and other basic B2B services that help subs and suppliers build 
their business. Phase I; however, will be limited to designing and maintaining the 
basic page, and may be subcontracted to a web page design service company. Page 
construction may also be performed outside of the Convex design group as long as 
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Convex design standards are met 



Gold Listing 



Performance and usability are of utmost importance. As mentioned earlier, the 
Target User- mid-sector of the A/E/C industry (subs) are far from being computer literate 
Interface and must not be intimidated by the user interface. We will be working with a 
group of individuals that have little or no tolerance for bugs, or confusion 
about what the next step is. We must provide a strong balance between a 
professional looking, but almost elementary-style basic GUI. Numbering data 
entry or service option steps may provide a clear action path for our users - 
Step 1 Step 2 Step 3.... 

A good example of a simple UI approach is AOL. While some of the more 
sophisticated users my think AOL is almost goofy looking the bulk of AOL's 
value is a direct reflection of their low mortality rate. We want to create UI that 
combines the speed of Yahoo with the simplicity of AOL. This is a critical 
design issue that drives the entire business proposition. 



PRLNT OF DRAW1AG5 
AS ORIG INALLY FILED 



G.C.'s will want the capability of having their own private database of 
bidders. Public database records should link with the G.C.'s private 
database - this will reduce the onerous responsibility of database 
maintenance by the G.C. 

Area codes are always changing. Convex administrators must have the 
ability of mass updating the database by associating new area codes to 
certain prefixes. This will be an on-going maintenance issue. If the 
process can be automated with local phone companies, it would gready 
enhance the system maintenance requirements. 

An import routine must be provided for quick set-up of the G.C.'s private 
database. Integration of data from BidFax, Oudook, Act and other contact 
management systems must be supported. A simple ASCII import with 
field-to-field mapping will be required. 

"Quick Fax" and e-mail templates must be provided for all users browsing 
the public and private database. Marking one or several recipients, then a 
fax or e-mail template with mail merge will be required. These are typically 
non-bid-related communications. Bid-related communications will take 
place within a bid portal 

Faxes and e-mails can only be sent by registered users. Fax and e-mail 
abusers will be terminated from the system. Security measures must be put 
in place to control this. We may want to prepare canned templates that are 
monitored by the system. 

Different views of the data must be supported - Single line view, full page 
per sub view, etc. If user definable can be supported without much pain to 
the user then do it! At a minimum, allow custom column viewing set-up 
for single or double line views. 

The public database will be copyrighted, however, we must provide a way 
to disallow downloading, OCR or any other mass copying of our data. 
Basic printed reports must be supported. Reports will be defined in the 
design spec. Most of the reports will be required at the private database 
level. 
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Functional Specifications 

Bid Manager - Phase I 

Convex Technologies, Inc. 



Executive Summary 

Convex's Bid Manager is a Pre-Construction Services Portal that enables commercial construction 
communities to participate in more efficient and cost effective bidding practices. 

The construction industry traditionally relies on manual methods of bid collaboration, and while two 
of the industry's leading news and project information services have improved the offering of 
computerized data, no single entity has attempted to provide a comprehensive mechanism that 
offers all of the components required to process an accurate and timely bid. In addition to offering 
news and information about upcoming bids, Bid Manager's portal will enable a more efficient 
connection of audiences by providing the following services: 

1. Fax and E-mail Bid Solicitation for General Contractors and Subcontractors 

2. Comprehensive Database of Subcontractors, Suppliers and Building Product 
Manufactures 

3. Bid collaboration tools for Architects, Engineers, General Contractors and 
Subcontractors 

4. Selective downloading of electronic plan images 

5. Key-word search and downloading of project specifications 

6. Networking over 1,200 blueprinters for hard copy reproduction of bid documents 

7. Electronic Bid Submission 

8. Historical tracking and electronic Bid Results 

9. General services including e-mail, weather, trade association links, news & events, Etc. 
Bid Manager's success will be directly related to the following critical assumptions: 

1. Plans and specifications can be seamlessly converted from their native .dwg format to a 
"Read Only" format that can be utilized for viewing, electronic estimating and digital 
printing 

2. Development of a security mechanism that offers all levels of open or restricted access 

3. An application interface that combines standard design and usability features with the 
idiosyncrasies of the construction community 

4. Utilization of the best available technology for the internet 

In an industry where rime and information are highly strategic components of the "New Business" 
process, Bid Manager stands to offer what nearly all successful business are willing to pay for — A 
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tool that minimizes resources and increases profits. We have the technology. Data and othet 
critical business components are readily available. The construction industry has been primed for 
Bid Manager. Raw talent and speedy execution will determine the stake that claims this new and 
exciting space. 



PRLNT OF DRAWINGS 
AS ORIGINA LLY FILE D 



Industry Overview 

The systematic, almost methodical, bid process experienced by today's construction industry is a 
result of nearly 150 years of competitive bidding and while the projects and players may differ from 
bid to bid the goal remains unchanged — To obtain the lowest possible price for die best 
possible materials and labor. 

Byproducts created from the evolution of this process were eventually converted to standards. 
Construction professionals in North America and Canada have adopted many of these bid practice 
standards, one of which is the final deadline for bid submission at 2:00 PM — ala Bid Manager. In 
addition to bid submission standards architects and engineers believed that organization of the bid 
documents by trade discipline would result in better bids. Today plans and specifications are 
prepared in a way that enables all participants to narrow down their required scope of work and 
submit a qualified bid. The model below represents how the organization of bid information 
resulted in a complementary business hierarchy: 



Architect 
& 

Engineers 



General Contractors 



Subcontractors 



Suppliers 
& 

Wholesalers 



Building Product 
Manufactures 



1 . Owner purchases land and employs the 
services of an architect and other 
consultants 

2. Architect employs services of specialty 
engineers and consultants 

3. Architect prepares bid documents 

4. Architect and owner seeks low bids from 
qualified general contractors 

5. General contractors seek low bids from 
qualified subcontractors and suppliers 

6. Subcontractors seek low bids from 
suppliers, wholesalers and building 
product manufactures 

7. Suppliers and wholesalers seek low bids 
from specified building product 
manufactures 

8. Building product manufactures submit 
bids 

9. Suppliers and wholesalers submit bids 

10. Subcontractors submit bids 

11. General contractors submit all-inclusive 
bid 
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While the above model appears to conform to a typical business transaction structure one should 
note that an intense strategy for winning the low bid exists within system. The community, will not 
accept merely providing a better vehicle for information dissemination — they will expect to 
maintain their ability to prepare a competitive bid. The framers of Bid Manager must be cognizant 
of the specific requirements of competitive bidding as outlined in sections to follow. 
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Bid Process Overview 

This section will describe the fundamental steps of the bid process. Emphasis will be placed on 
describing the unique roll each segment plays in the process. Bid Manager's infrastructure and 
interface should be flexible enough to accommodate "Look and Feel" customization by segment 

Types of Bids 

Bid Manager will be primarily designed to meet the needs of the commercial/ indus trial and building 
industry; however, consideration for US infrastructure projects such as roads, dams and bridges 
should be implemented into the roots of the system for future use (see supplemental infrastructure 
design documents). 

There are typically five (5) types of bid scenarios - they are as follows: 

1 . Public Works (City/State/Federal Government) - Typically public works projects 
are open to anyone and everyone that qualifies to bid the project Highly competitive 
bid environment Strong consideration for "Equal Opportunity Employment" exists in 
most states. Preferential bidding, based on race, continues to be challenged across 
America. No such bidding criteria exist in Canada. Fields describing Minority, Women, 
Disadvantaged Veterans and Small Business may become a critical option for database 
design. 

2. Private Competitive Bid - Private ownership (s) where more than one General 
Contracting bid is desired. Heavy competition amongst general contractors and 
subcontractors. Provisions for Union Labor may be required if funds come from Union 
lending institutions. Prevailing labor rates may be mandated if a portion of the funds 
come from a Government funding program. Database design should allow for 
identification of Union or Prevailing Wages. 

3. Negotiated Bid - Ownership places confidence in a single General Contractor. 
General Contractor will solicit bids from qualified subcontractors and suppliers. 
Provisions for Union Labor may be required if funds come from Union lending 
institutions. Prevailing labor rates may be mandated if a portion of the funds come from 
a Government funding program. Database design should allow for identification of 
Union or Prevailing Wages. 

4. Design/Build — Ownership selects one general contractor to assist architect with 
design and bid documents in order to meet the constraints of the development budget 
Some design/build contracts call for the General Contractor as the lead in lieu of the 
Architect General Contractor will solicit bids from qualified subcontractors and 
suppliers. Provisions for Union Labor may be required if funds come from Union 
lending institutions. Prevailing labor rates may be mandated if a portion of the funds 
come from a Government funding program. Database design should allow for 
identification of Union or Prevailing Wages. 

5. Re-Bid - Sometimes a project will either come in over budget or the economy may 
adversely change and delay the bid award process. In these case a project may com out 
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as a re-bid. For this reason provisions within the database design must accommodate re- 
bid projects. 

Project types 2, 3 and 4 will require tight security controls that empower the owners, architects and 
general contracts with the ability to keep the project from getting into the hands of their 
competitors. This will be of great concern to Owners, architects, engineers and general contractors. 

The Owner 

Owners are typically comprised of the following entities: 

1. Single entity/private ownership 

2. Partnerships and joint ventures 

3. Corporations (Wal-Mart, McDonalds, Etc.) 

4. City, State and Federal Government agencies 

While the owners roll in the bid process is typically limited to performance motivation, they will 
always want to have their fingers in every aspect of the process. The owners' main goal is to secure 
the financing and employ consultants that meet or beat the expectations of the financial pro forma. 

Identifying qualified consultants and collaborating within Bid Manager will provide great value to 
the owner. Typical collaboration expectations from the owner are as follows: 

1. Delivery of Request for Proposals (RFP's) to qualified architects and engineers 

2. Exchanging design and building program requirements with architects and engineers 

3. Identifying qualified consultants and requesting information about their services 

4. Organizing meetings and job site visits with team members 

5. Identifying qualified general contractors by work type and prior performance 

6. Delivery of Request for Proposals (RFP's) to qualified general contractors 

7. Reproduction and delivery of plans and specifications 

8. Searching for and viewing currently available building product materials and requesting 
preliminary pricing 

9. Providing press releases and other public relations information 

10. Marketing and sales of real estate 

The owner of the project will become a key advocate of Bid Manager's efficiency capabilities. 

Architects and Engineers 

Architects are typically expected to lead the bid process. Following receipt of a signed contract from 
the Owner the Architect will commence preparation of the following documents: 
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\. Preliminary schematics - Typically consists of a site plan, floor plan and conceptual 
elevations. 

2. Preliminary plan submission to City - Agency specific requirements, but typically 
includes preliminary schematic documents accompanied by form documents provided 
by the local City or County. 

3. Preparation of Bid Documents - Consists of all documents required to accurately bid 
the project Bid documents also include Addenda - a change to the original bid 
documents. 

4. Plan Check - Submission of final design documents for code and occupancy use review 
and approvals. Generally consists of all bid documents and any changes resulting from 
the bid process. 

5. Construction Documents - Modified bid documents incorporating all comments from 
bidding process and plan check. Documents used to construct project 

6. Contract Administration - Some Architects may also coordinate prime contract 
agreements and perform other contract administration activities for the owner. 

Critical elements for Bid Manager and the Architect are as follows: 

1 . Project information - Each project will be set up with its own unique profile. The 
architect must be able to quickly point and click on Bid Manager's pre-defined lists. 
Preferences must allow non-applicable list items to be hidden for quicker set-up. Project 
information may include, but may not be limited to the following: 

a. Tide 

b. Location 

c. Bid Date and Time 

d. Owner Information 

e. Architect Information 

f. Consultant Information 

g. G.C.'s Bidding Information 

h. Type of project (Up to 25 types) 

i. Estimated valuation 

j. General Scope of work description (100 words) 

k. UCI/CSI list of trades or key word indexing on disciplines required 

Note: A cumulative list of bid participants by segment should be tracked and made available at 
the request of the security administrators. 

2. Bid document formats and organization - Every project consists of plans, 
specifications, addenda and other related documentation. The purpose of these 
documents is to provide a consistent format for bid submission and create the basis for 
executing future contracts. 



a. Plans - Plans are typically prepared in a computerized format called ".dwg". Bid 
Manager's architectural interface must provide for simple project set-up and 
ati'ministration by the architect. Architects will not allow their .dwg files to be 
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publicly disseminated. Painless file conversion will be requited for the following 
critical purposes: 

1 . Painless viewing while on-line 

2. Downloading for electronic estimating 

3. Downloading for digital printing 

Individual plan sheets must be organized in folders by consultant discipline as 
follows: 

1. Architectural 

2. Structural 

3. Plumbing 

4. Mechanical/HVAC 

5. Electrical 

6. Landscape 

7. Civil 

8. Other 

Note: If plans are not available in electronic format all efforts should be made to 
link the designated printer to the bid team for easy ordering of bid documents. 

b. Specifications — Specification books are typically prepared in an electronic word 
processing program. All specification booklets will be converted to .pdf file 
format and organized by the industry standard UCI/CSI major division codes as 



follows: 




01- 


General Requirements 


02- 


Site Work* 


03- 


Concrete 


04- 


Masonry 


05- 


Metals 


06- 


Woods and Plastics 


07- 


Thermal and Moisture Protection 


08- 


Doors and Windows 


09- 


Finishes 


10- 


Specialties 


11- 


Equipment 


12- 


Furnishings 


13- 


Special Construction 


14- 


Conveying Systems 


15- 


Mechanical 


16- 


Electrical 


17- 


Other 



* Note: Soils report documents will be contained within division 02 - Site Work 



PRLNT OF DRAWLNGS 

AS ORIGINA LLY FILED | ^ 



c. Addenda - Addenda must be treated as "Urgent" documents throughout the 
architecture. Addenda change bid dates, bid documents and bid meetings on a 
regular basis. Accurate bid submission is contingent on timely receipt of 
addenda information. A separate and distinct folder will house all addenda 
information and will be organized as follows: 

- Addenda 

- Addenda 1 March 23, 1999 
Plans 
Specs 

-Addenda 2 April 2, 1999 
Plans 
Specs 

Indexing all addenda information into a search index would greatly enhance the industry addenda 
processing problems. (Key word match and group by major CSI division) E-mail and paging 
services should be linked to the addenda processing system. 



3. Other Correspondence — Architects and Engineers will require other basic tools for 
standard bid collaboration. The action list below represents a preliminary list that may 
change as feedback is received from beta testers: 



a. RFI Processing — RFI's or Request for Information correspondence is critical 
during the bid phase. General contractors often receive questions from qualified 
subcontractors regarding product specifications, installation details and/ or 
alternate material submission. RFI's typically create addenda. Addenda legally 
modify the bid documents. The RFI processor is a simple word processing tool 
that automatically tracks and forwards information to the correct team menders 
— similar to Project Net's Submittal Processing system. 

b. Alternate Product Inquiry - Building Product Manufactures often submit 
requests for alternate materials when their product names are not listed in the 
specification book Architects need an organized submission vehicle and a 
simple form of approval processing. HTML linking within the inquiry to the 
BPM's web site may gready enhance this process. 

c. Pre-Bid Meeting Notification - Some projects require a pre-bid conference with 
the architect and the owner. Home Depot never bids a job without a pre-bid 
conference. 

d. Electronic Bid Submission — Most bids are submitted in person today; however, 
Bid Manager may modify this protocol. For this reason the system must support 
electronically submitted bids. The architect will want to create a bid form so that 
all the bids are consistent and easily evaluated. Contractors will simply fill in the 
blanks and click on SUBMIT BID NOW. The "submit bid now" screen would 
look nice with an analog clock in the corner! 
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e. Bid Withdrawal Form - Contractors often withdrawal from the bid process. A 
form with predefined reasons for the withdrawal will be helpful to notify all 
involved in the bid process to-date. 

f. E-mail — We may want to provide free e-mail services. 

The Print Network 

A key ingredient for Bid Manager's success is the ability to process comprehensive reproduction 
services for plans and specifications. In a perfect world the architect will submit plans and 
specifications in formats that can be painlessly converted to printable images as outlined above. A 
significant portion of Bid Manager's e-commerce plan is to link digitally enabled printers to the 
audiences requiring hard copy plans and specifications. The print processing network should be 
designed as follows: 

1. Utilizing the document organization structure shown above, the ordering system must 
allow picking and choosing of individual plan sheets and specification sections. Use 
"Add to shopping cart" methodology. Each set of bid documents must be packaged and 
re-capped by job tide. 

2. Provide for "frequent flyer" purchasing and/ or large order discounts. 

3. Provide comprehensive ordering, fulfillment and billing system. (Fed-x partnering?) 

4. Potential for automatic profiled delivery system. (Painting sub wants Architectural 
sheets and section 09900 of the specifications delivered each week within a designated 
geographic location) 



The General Contractor (GC) 

The GC is responsible for providing an all-inclusive turnkey bid for the project. GC's are bound to 
their bid by language contained within the bid documents. The challenge for the GC is to get as 
many competitive bids as possible from qualified subcontractors and suppliers before the 2:00 PM 
deadline. Bid Manager will greatly enhance the GC's competitive capabilities by providing the 
following basic services: 

1 . Search for, or automatically receive, new bidding opportunities 

2. Organizing and tracking a list of pre-qualified subs and suppliers 

3. Access to hundreds of thousands of subs and suppliers that are organized by UCI/CSI 
trade codes 

4. Automated fax and e-mail bid solicitation to subs and suppliers 

5. Automated bid response from subs and suppliers 

6. Automated print processing of plans and specifications from print network 

7. Quick and simple RFI submission to architects and engineers 

8. Speedy notification and delivery of addenda information 

9. Easy processing of "Scope Letters", "Bid Memos" and "Bid Submission Forms" to team 
bidders 
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10. "Work from Anywhere" bid collaboration platform 

11. Electronic bid submission from subcontractors and suppliers 

12. Electron bid submission to Architects 

13. Historical tracking and 24 hr. monitoring of bid process 

14. Multi station bid processing within one seamless platform 

15. Automated purchasing and award notification (contract processing) 

16. Easy transition to "Web-based Project Management" 



Following is a brief description of how each of the above features will function within the Bid 
Manager environment: 

1. Search for, or automatically receive, n ew bidding opportunities (marketing! 
a GC's will utilize the "Project Data" as entered by the architect to find new 

bidding opportunities. Locating all industrial tilt-up bidding opportunities in a 
geographic region is one example of this valuable search benefit 

b Many GC's will pay for Bid Manager to automatically deliver bidding 

opportunities based on pre-defined criteria. GC's can retrieve the data at any time 
while the system updates the mailbox, as new data becomes available. 

c After the project list is drilled down the GC will want to deliver a "Request to 
Bid" inquiry to either the architect or owner. This may become a form letter within 
Bid Manager. 

d A simple project tracking and calendar system will help GC's track and manage 
their bidding opportunities. 

2. Organizing and tracking a list of pre-qualified s ubs and suppliers 

a. GC's will want to maintain and track their own private list of subs and suppliers. 
Bid Manager's database structure should allow GC's to manipulate and manage two 
sets of intelligent data. Subs and suppliers should also be capable of updating the 
profile direcdy, only if the GC's admin preferences are set accordingly. 

b. The database structure will mimic a typical contact management database, but 
will be uniquely organized by the UCI/CSI code indexing system. A one-to-many 
relationship must be available for subs and suppliers that perform more than one 
trade. 

c. Standard report writing should be provided for creation of printed lists. 

d. Basic import and export capabilities must be supported for easy set-up of the 
bidder list 

3. Access to hundreds of th ousands of subs and suppliers that are organized by 
UCI/CSI trade codes 

a. This will be a major benefit of Bid Manager's product offering. GC's will use this 
data as a supplement to their private database of subs and suppliers. Similar to 
section 2 above, all data will be organized by the UCI/ CSI index of codes and will be 
managed in a typical contact management database environment unique to 
construction bidding. 
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b. GC's must have the capability of moving data from the public list to their own 
private list A distinction between the origin of data must be provided prior to 
adding to private list 

c. Subs and suppliers that pay for advertising will be listed in "Top-of-List" priority for 
easy selection by the GC 

d. General use fax and e-mail templates should allow quick and easy communications 
direcdy from the private or public list of subs and suppliers. 

4. Automated fax and e-mail bid solicitation to subs and suppliers 

a. The Bid Management capabilities of Bid Manager will become the heart of the 
product GC's will need to organize a bid list quickly and notify qualified subs and 
suppliers by fax and e-mail. 

b. Each project must be organized as its own entity. Many projects will be set-up 
by the owner or architect and forwarded to the GC for bid processing. Not all 
projects will be set up by the architect GC's will use Bid Manager without electronic 
plans and specs. 

c. All bids will be organized by UCI/CSI code indexing. Filtering out subs and 
suppliers by fields representing geographic bidding preferences will be supported. 
Locating subs with labor and other work preferences will also be required. 

d. A point and click selection process will allow the GC to narrow don a preferred 
list of subs and suppliers. 

e. Templates will enable quick and simple broadcast fax and e-mail processing. 

f. Printed reports will facilitate the requirements of hard copy documentation. 

g. Non bid related faxes and e-mails must be permitted within the system. 

h. A 1-800-fax response server will be used to automatically rout RSVP's back to 
the appropriate GC. OCR recognition capabilities will be required for fax routing. 

i. GC's will require bid solicitation activity reports showing bid coverage by 
UCI/CSI trade. If bid response is low additional faxes and e-mails will be sent to 
subs and suppliers selected from the public list 

j. Proof of "Good Faith" solicitation to qualified minorities, women, disadvantaged 
veterans and small business may be required on certain public works bids. 

5. Automated print processing of plans and specifications from print network 

a. Over $2.0 billion is spent each year on reproducing bid documents. Fed-x 
collects over $300 Million from shipping plans in tubes. Bid Manager will gready 
enhance the printing and decimation process. GC's must have the capability of pre- 
purchasing plans for a select group of subs and suppliers. All other interested subs 
and suppliers must direcdy purchase from the printer. Pre-purchased plan 
information is not for public use. 

b. GC's will want to submit an order to several vendors to obtain the best possible 
printing price. 

c. The bid document-ordering module should be a unique feature of the interface - 
easy-to-use and reliable. 

6. Quick and simple RFI submission to architects and engineers 

a. GC's will need a simple template to create, submit and tract questions submitted 
to architects and engineers. 

b. Utilize pull-down lists make RFPs easy to prepare and send. 
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c. Some of the RFI's will be directly forwarded to the architect as they come in 
from the subs and suppliers. Admin preferences should allow automatic forwarding 
with copies in the GC's inbox. 

d. History tracking will be required. 

7. Speedy notification and delivery of ad denda information 

a. The average bid experiences 5 addenda prior to bid day. Some projects will have 
50 to 100 addenda. Addenda consist of revised bid dates, modified plans and specs, 
and adjusted meeting dates and times. 

b. All addenda information will be housed in a separate folder called "Addenda" 
with sub folders called 'Tlans" and "Specs". 

c. Special fields will be provided to capture modified bid dates or meeting dates. 
Other buttons may be used to signify changed plans or spec sections. 

d. A key-word index can be used for automatic notification or search inquiry of 
trades affected by the addenda. 

e. Addenda are typically labeled 1-N or A-Z. 

f. All electronic bid submission templates should note receipt of addenda, i.e. This 
bid includes the following addenda. . .1, 2, 3 and 4. 

8. Easy processing of "Scope Letters", "Bid Memos" and "Bid Submission Forms" 
to team bidders 

a. GC's will use templates to organize questions and broadcast them to certain 
members of the bid team. This feature will help maintain, and possibly increase the 
GC's competitive edge. 

b. All templates are UCI/CSI code driven - pull down list of codes. 

c. Uses pull-down list of bid team based on selected codes for memo or scope 
letter. 

d. Will need to fax and e-mail forms, similar to bid solicitation. 

e. Unique folders house responses from subs and suppliers. 

9. "Work from Anywhere" bid collaboration platform 

a. Bid set-up stuff! Not complete yet! ************************** 

10. Electronic bid submission from subcontractors and suppliers 

a. GC's will receive bids from subs and suppliers. Allowing the GC to prepare a 
custom bid form for each bid will help facilitate a consistent retrieval and bid 
evaluation process. 

b. Many subs and suppliers will use a standard e-mail attachment protocol for 
submitting bid proposals. (Attach an Excel or Word file) 

c. Subs and suppliers will want verification that the bid was delivered successfully. 

11. Electron bid submission to Architects 

a. Architects may want to prepare bid forms that can be submitted by the GC. 
GC's can fill in the blanks, add information and submit the bid via Bid Manager. 

12. Historical tracking and 24 hr. monitoring of bid process 

13. Multi station bid processing within one seamless platform 

a. Large projects often require the efforts of several employees. Bid 
Manager should allow real-time access by to all levels of the application. 

b. Standard AIA contract documents control 90% of the industry's 
agreements. Automating this piece of the business will require creativity and vision. 
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14. Automated purchasing and award notification (co ntract processing) 

a. After a bid is awarded GC's will need to lock-in material prices. Bid Manager 
should provide a simple contract purchasing and award processing system. This 
system will ultimately drive most of Bid Manager's future revenue. 

15. Easy transition to a standard proje ct management package (Primavera. Meridian 
Systems r etc) 

a. If a bid team utilizes Bid Manager to win a bid they will be highly motivated to 
continue the construction management process in a similar environment 

Subcontractors 

It is important to understand that the subcontractor is the lifeblood of the general contractor. Deep 
relationships are nurtured and mai n tai n ed in order to combat heavy bid competition. Bid Manager 
will flourish if the subs can enhance their bonds with the GC. The framers of Bid Manager must 
incorporate the ability to collaborate in an environment that is easy to use and highly secured. 

While some of the more sophisticated subs will perform similar functions as the GC, the vast 
majority will expect the following capabilities: 

1. Search for, or automatically receive new bidding opportunities 

a. Searching by using one or more of the following criteria will be required (including 
Boolean logic): 

1. UCI/CSI trade 

2. Keyword(s) 

3. Project type (commercial, schools, retail, etc.) 

4. Geographic Location 

5. Valuation 

6. # of Days before bid is due 

b. Set preferences and have data automatically delivered to bid inbox 

c. Manage bidding opportunities in a calendar package similar to or linked to Outlook 

d. Directory services activity automatically sent to sub 

e. Directory services link to sub's web site 

f. Creation of a custom portal for the sub 

1 . Marketing and promotion 

2. Manage relationships with BPM's 



Suppliers, Wholesalers and Building Product Manufactures 

One of the greatest challenges for the BPM segment is locating new projects during the design 
phase. As the Bid Manager piece becomes more populated with data the BPM will see great value in 
having access to the information. The BPM segment will require the following capabilities: 
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1. Same as sub above, and. . . 

2. Receiving e-mail and fax leads from subs and G.C.'s 

3. Sending quotes and/ or bids to subs and G.C's 

4. Locating projects containing their own products or the requirement for similar products 

5. Hot-linking anyone to the BPM web site 

6. Creation of a custom bid portal that meets Convex's standards for future e-commerce 
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1 Import will be from a common delimited file only - no need to concern which system the 
1 data is coming from 


1 Import capability to bring in all subs - how to sync this up with the public database? 


I Must create map of private CSI codes to standard Convex Codes 


1 Select to convert private CSI codes to standard Convex Codes 


I Import user's logo from BidFax 


I Import BidFax letter text for freeform memos 


| Sales, Support, etc. 


1 Billing Module must be flexible 


I Able to process credit card transactions - collect payment 


| Invitation to Bid 


| Addenda 


| Memo / Scope Letter 


DC 


Other (Free Form) 

•Allow contractor to create own templates including their logo (.dcx file 8" x 3") 


Instructions to Bidders 


Q- 

DC 


Bid Documents (Input to the GC) 
•Plans 

• Arch 

• Structural 

• P.M.E 

• US 

• Civil 

• Other 
•Spec's Book 
•Instructions to Bidders 
•Supplier Documents 

• Soil Report 

• Environmental Impact 

• Local Government Stuff 


General Conditions and Fee Proposal J 


Provide quarterly reports to show subcontractors how they could buy ratings 1 


Reports to monitor who is getting what communication 1 


Maintain log of documents and flow by project | 


1 Data Conversion 


Data Conversion 


Data Conversion 


Data Conversion 


Data Conversion 


Data Conversion 


Support Services / Call 
Center 


Billing 


1 Billing 


Types of Documents 
(formsAemplates) 


Types of Documents 
(formsAemplates) 


Types of Documents 
(formsAemplates) 


Types of Documents 
(formsAemplates) I 


Types of Documents 
(formsAemplates) 


Types of Documents 

| (formsAemplates) | 


Types of Documents 
I (formsAemplates) I 


Types of Documents 
(formsAemplates) 


Types of Documents 
(formsAemplates) I 


Types of Reports I 


Types of Reports 1 


Document Management | 
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Role based security 1 


Security so vou can't see how I'm oraanizing & who I'm sending to 1 


Is it aoina to be windows only or webtv UNIX Mac. net clients? 1 


Give DeoDle the capability of receiving faxes on bid day 1 


Conversion from bid fax to Convex 1 


Personal email chanae or forwardina is easy 1 


Custom web Daae 1 


Convex takes care of back-ups 1 


I'll aet an email suaaestina chanaes to my file e.g. area code change 1 


Easy to Update 1 


Invisible Technoloav 1 


OCR for fax response 1 


Easv to recall password if forgotten 1 


Time to Market 

•GC needs to get subs involved in first 3 days to beat competitors 
•6 hr. or ovemiaht to fax v. 15 min to aet faxes out 


Incorporate your logo I 


I can find subs in Las Veaas even though I've never been there I 


I can reaister and tell vou exactly what I do I 


Summary of current Convex activity 

• e.g. there are 1 65,000 projects w/ 1 6,500 in your area of which 2,350 have 
specialized door needs 


I can see mv competitors - (aood & bad) I 


When you get a project w/ my profile send it to me 


| 

i 

I 

3 

5 

3 
0 

o 
I 
I 

0 

I 

°- c 

8 I 

d m 


Tarqeted Marketing 
Stepped Membership 


I'm not lookinq for projects I'm looking for GC's w/ projects 
Can find competition 


1 Silver uoarade proiects iust outside vour area - vou can get a report 


Notice if there are a lot of projects just outside user's parameters that they would not 
1 know about 


Can Originate or Use "off the shelf" Templates 
•Templates can be based on: 

• Owners e.g. Home Depot 

• Type of Construction e.g. Tilt-up, Bridge, etc. 

• Standard Bid Form 

• Exception Templates 

• Can Match users Word doc to the Send List 

• Reports or Forms - need some examples 

• Templates should be available for any type of use that makes sense 

• Need to identify other areas where Templates would be useful 


1 
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Technoloav 
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Technology 


Technology 


Technoloav 


Technology 


Technology 


Technology 


Technoloav 


Technology 


Technology 


Marketing 


Marketing 


Marketina 
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Marketing 


Marketina 


Marketing 
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Marketing 
Marketing 
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Marketina 
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Tools 
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Monitor Bid Coverage 
•Easy to Monitor 

• What will make it easy 
•Sensitivity Factors 

• What Factors do you need to watch 
•Responsiveness 

•Analysis 

• What ratios do we want to use? 
•Plan Acceptance by Subs 

• "Subs aren't accepting your plans, but want to bid - looks like you're getting in 
too late" 

•Specific Reports 

• e.g. owner can review minority women coverage 

• e.g. you've got to be able to show the union you tried to get them involved 

• What are all the reports we need to build? 


Reports on my Convex Activity 

•report can tell me how 1 can do better - e.g. become a silver or bronze 
• What else? 


Reports on my Convex Benefits 

•there have been 30,000 people looking for painters get going 

• What else? 
Personalized 


Role Specific 
Search Results 
•Categorized 

• Not Obscure Titles 


Generals can Control Specs & Plans 
•What specifically does this mean? 


Able to Customize Specs & Other Documents 

• What are the other documents? 
Architects & Others don't have to use UCI/CSI 


Able to deal w/ deposits for plans 

Control Communication Coming to You & Lists You Send to 
•Specify Type of Info to Receive by Type & by Sender 
•Specify Type of Bids to Accept & Distribute by Preferences 
•Flexible SDecifications bv Cateaories & Subcategories 


Organization 

•Gives Summary of what's in the System - e.g. 3 negotiated 12 private 16 public 
•Organized in Tree Format like Outlook 

• Default Tree 

• Wizard can help Customize 

Can Cateqorize bv Yes, No. Maybe, Trash Can, In Process 
Can Cateqorize by Contractor 


Reports 


Reports 


Reports 

Other Dav to Dav Functions 


Other Day to Day Functions 
Other Day to Day Functions 


Other Day to Day Functions 


Other Day to Uay functions 
Other Day to Day Functions 


Other Day to Day Functions 
Bid Info 


Bid Info 

Bid Info 
Bid Info 
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1 Can Categorize by Project 


1 Can Prioritize by Contractor, Project, Most Recent Message, Urgent Messages, Type of 
Message, Open v. Unopened, Flag Status 


I Categorization & Prioritization Filtered by System 


1 Strings on Wall to Organize Project Information Flow 
1 • Organize RFI 


Features 

•Confirmation of Delivery [liabilities] 

• Sent 

• Received 

• Viewed 

•History Log like blueline/online 

• When Recipient opened it, how long it was open, how many times they opened 

it 

•Can view Activity Along the Whole Chain w/ Permission 
•Can Disassociate Companies that aren't Responding to an Individual Project or in 
General 

•Notification that plans have been ordered and sent 

•If email isn't Viewed in a Specified Amount of Time a Fax or Page can be Sent 
•If a Response isn't Received in Specified Time another Email Can be Sent to ask if 

they want it or not 
•Recipient can Respond back on the Same Email received 
•Always Accept Feature 
•Inbox Search Function 
•Archive 

•Failed Faxes w give me a reason why 

•GC must be able to customize information from A/E 

•GC must be able to flag packets e.g. Mervyns generators 


Addenda can have Separate Inbox & Paging I 


Cut & Paste Addenda Received so its Relevant to Who you Pass it on to 1 


Sending of Addenda can Activate Paging I 


Strategy 

• Only send addenda to who you really want to or are working w/ so it 
doesn't flow back up to your competitor 

• Send Memos and addenda to active participating pieces 


Fax back to GC direct or through our system so we could track 1 


1 can send my private record of my favorite framer to my brother in law who's getting 1 
started | 


Cant spam the group 1 
• Charge for huge volumes of mail I 


Even though the recipient might match 50 codes e.g. supplier - only one fax is generated 1 
not 50 | 


May be their only email | 


Junk Mail by Category | 


1 Bid Info 


Bid Info 


Bid Info 


Bid Info 


Bid Info 


Addenda | 


Addenda 


Addenda | 


Addenda 


Other Features 


Other Features 


Other Features 


Other Features 


Other Features 


Other Features | 
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